Re: Aggregate all bundle.yaml | API endpoint

[Merlijn Sebrechts]

As Marco said; The direction is purely semantical; it provides some
information about what the relation represents but it doesn't specify the
direction of a data flow or something else. A relation always connects a
"provides" endpoint with a "requires" endpoint, you can see this as the
relation having a direction. If you want to know the direction of a
relationship, you need to look at the endpoints in the metadata.yaml of
both charms and see which is the provides side and which is the requires
side.

Also note that relations denote an operations-level (management-level)
dependency. This does not necessarily mean that there is data flowing
between the *applications* themselves, only that the charms who manage the
applications share data.


On Thu, 5 Jul 2018, 07:49 Ilias Tsoumas,  wrote:

> Ok, it is clear.
> Also, how I identify the "direction" of relationship? It is denoted with
> order of the dashes?
> *- - :*
> *  - :*
> imply that the data-flow from  ** is directed in
> **
> and
> *- - :*
> *  - :*
> imply that the data-flow from  ** is directed in
> **
>
> On Thu, Jul 5, 2018 at 5:10 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> There is nothing preventing directed cycles in the graph, although I'm
>> not sure how common they are in real bundles.
>>
>> On Thu, 5 Jul 2018, 05:57 Ilias Tsoumas,  wrote:
>>
>>> Merlijn thank you for your reply. It was enlightening about the
>>> relations of charms.
>>> Only a comment till now, is each bundle a directed acyclic graph (DAG)?
>>>
>>>
>>> On Tue, Jun 26, 2018 at 7:10 PM Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
>>>> The format is
>>>>
>>>> - - :
>>>>   - :
>>>>
>>>> Where application-name is the name of the _instance_ of the charm (as
>>>> defined in the applications section of bundle.yaml) and endpoint-name is
>>>> the name of the endpoint (requires/provides from metadata.yaml) that is
>>>> used to connect the two nodes.
>>>>
>>>> Endpoint-name is optional if only one type of relation is possible
>>>> between the nodes (a relation is established between a required endpoint of
>>>> one node and a provides endpoint of the same interface type of the other
>>>> node). The : is not present if the endpoint name is not specified.
>>>>
>>>> So the relations section is a 2 dimensional list, the first dimension
>>>> is an array of all the relations and the second dimension specifies which
>>>> endpoints of which nodes that relation connects.
>>>>
>>>> And finally, the applications section is called "services" in some
>>>> bundles.
>>>>
>>>> I think that covers most of the strange quirks, let me know if you have
>>>> more questions.
>>>>
>>>> On Tue, 26 Jun 2018, 05:37 Ilias Tsoumas,  wrote:
>>>>
>>>>> Hello Merlijn and all,
>>>>>
>>>>> I developed a python script which fetching all the bundle.yml.
>>>>> Here is the repo: https://github.com/itsoum/BundlesFetcher
>>>>> Merlijn special thanks for the help about the API.
>>>>>
>>>>> Now, there rise a new "problem". As I had mentioned in the first-post
>>>>> above I fetch bundles for the relations between nodes(charms). But there
>>>>> isn't an obvious annotation technique about how relations are described
>>>>> inside each bundle.yaml.
>>>>> Check some different examples below
>>>>>
>>>>> https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/wordpress-site-3.yml
>>>>>
>>>>>
>>>>> https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/web-in-a-box-9.yml
>>>>> <https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/wordpress-site-3.yml>
>>>>>
>>>>>
>>>>> https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/hadoop-spark-1.yml
>>>>> <https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/wordpress-site-3.yml>
>>>>>
>>>>> For example in the first:
>>>>> relations:
>>>>> - - haproxy:reverseproxy
>>>>> - wordpress:website
>>>>> - - wordpress:cache
>>>>> - memcached:cache
>>>>> - - wordpress:db
>>>>> - mariadb:db
>>>>> - - mariadb-sl

Re: Aggregate all bundle.yaml | API endpoint

[Merlijn Sebrechts]

There is nothing preventing directed cycles in the graph, although I'm not
sure how common they are in real bundles.

On Thu, 5 Jul 2018, 05:57 Ilias Tsoumas,  wrote:

> Merlijn thank you for your reply. It was enlightening about the relations
> of charms.
> Only a comment till now, is each bundle a directed acyclic graph (DAG)?
>
>
> On Tue, Jun 26, 2018 at 7:10 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> The format is
>>
>> - - :
>>   - :
>>
>> Where application-name is the name of the _instance_ of the charm (as
>> defined in the applications section of bundle.yaml) and endpoint-name is
>> the name of the endpoint (requires/provides from metadata.yaml) that is
>> used to connect the two nodes.
>>
>> Endpoint-name is optional if only one type of relation is possible
>> between the nodes (a relation is established between a required endpoint of
>> one node and a provides endpoint of the same interface type of the other
>> node). The : is not present if the endpoint name is not specified.
>>
>> So the relations section is a 2 dimensional list, the first dimension is
>> an array of all the relations and the second dimension specifies which
>> endpoints of which nodes that relation connects.
>>
>> And finally, the applications section is called "services" in some
>> bundles.
>>
>> I think that covers most of the strange quirks, let me know if you have
>> more questions.
>>
>> On Tue, 26 Jun 2018, 05:37 Ilias Tsoumas,  wrote:
>>
>>> Hello Merlijn and all,
>>>
>>> I developed a python script which fetching all the bundle.yml.
>>> Here is the repo: https://github.com/itsoum/BundlesFetcher
>>> Merlijn special thanks for the help about the API.
>>>
>>> Now, there rise a new "problem". As I had mentioned in the first-post
>>> above I fetch bundles for the relations between nodes(charms). But there
>>> isn't an obvious annotation technique about how relations are described
>>> inside each bundle.yaml.
>>> Check some different examples below
>>>
>>> https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/wordpress-site-3.yml
>>>
>>>
>>> https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/web-in-a-box-9.yml
>>> <https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/wordpress-site-3.yml>
>>>
>>>
>>> https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/hadoop-spark-1.yml
>>> <https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/wordpress-site-3.yml>
>>>
>>> For example in the first:
>>> relations:
>>> - - haproxy:reverseproxy
>>> - wordpress:website
>>> - - wordpress:cache
>>> - memcached:cache
>>> - - wordpress:db
>>> - mariadb:db
>>> - - mariadb-slave:slave
>>> - mariadb:master
>>> - - nagios:nagios
>>> - wordpress:juju-info which is the topology of application graph. The
>>> ':' isn't denotes the edge between two charms? If yes, why - wordpress:db
>>> and - mariadb:db?
>>> There us someone who knows the annotation method of relations? Could you
>>> explain?
>>>
>>> BR,
>>> Ilias
>>>
>>>
>>>
>>>
>>> On Tue, Jun 5, 2018 at 2:11 PM Ilias Tsoumas  wrote:
>>>
>>>> Hi Merlijn,
>>>>
>>>> First of all thank you for your quick and essential answer!
>>>>
>>>> Reply inline
>>>>
>>>> Great to hear you're doing cool stuff with Juju! I recently asked a
>>>>> similar question for a paper I've written for CLOUD 2018
>>>>> https://lists.ubuntu.com/archives/juju/2018-January/009845.html. If
>>>>> you want, I can send it to you in private (it's accepted but not published
>>>>> yet).
>>>>>
>>>>
>>>> Of course. I would like to read your paper. Also me and a colleague
>>>> work on performance estimations of app components (=charms). If I have
>>>> suspected properly your paper is related with performance
>>>> analysis/profiling thus it will be inspiration for us.
>>>>
>>>> Here is the documentation for the charm store api:
>>>>> https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md
>>>>>
>>>>
>>>> I will check it.
>>>>
>>>> Here is an Jupyter notebook I use to get metrics of charm and l

Re: Aggregate all bundle.yaml | API endpoint

[Merlijn Sebrechts]

The format is

- - :
  - :

Where application-name is the name of the _instance_ of the charm (as
defined in the applications section of bundle.yaml) and endpoint-name is
the name of the endpoint (requires/provides from metadata.yaml) that is
used to connect the two nodes.

Endpoint-name is optional if only one type of relation is possible between
the nodes (a relation is established between a required endpoint of one
node and a provides endpoint of the same interface type of the other node).
The : is not present if the endpoint name is not specified.

So the relations section is a 2 dimensional list, the first dimension is an
array of all the relations and the second dimension specifies which
endpoints of which nodes that relation connects.

And finally, the applications section is called "services" in some bundles.

I think that covers most of the strange quirks, let me know if you have
more questions.

On Tue, 26 Jun 2018, 05:37 Ilias Tsoumas,  wrote:

> Hello Merlijn and all,
>
> I developed a python script which fetching all the bundle.yml.
> Here is the repo: https://github.com/itsoum/BundlesFetcher
> Merlijn special thanks for the help about the API.
>
> Now, there rise a new "problem". As I had mentioned in the first-post
> above I fetch bundles for the relations between nodes(charms). But there
> isn't an obvious annotation technique about how relations are described
> inside each bundle.yaml.
> Check some different examples below
>
> https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/wordpress-site-3.yml
>
>
> https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/web-in-a-box-9.yml
> <https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/wordpress-site-3.yml>
>
>
> https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/hadoop-spark-1.yml
> <https://github.com/itsoum/BundlesFetcher/blob/master/bundles_yaml/wordpress-site-3.yml>
>
> For example in the first:
> relations:
> - - haproxy:reverseproxy
> - wordpress:website
> - - wordpress:cache
> - memcached:cache
> - - wordpress:db
> - mariadb:db
> - - mariadb-slave:slave
> - mariadb:master
> - - nagios:nagios
> - wordpress:juju-info which is the topology of application graph. The ':'
> isn't denotes the edge between two charms? If yes, why - wordpress:db and -
> mariadb:db?
> There us someone who knows the annotation method of relations? Could you
> explain?
>
> BR,
> Ilias
>
>
>
>
> On Tue, Jun 5, 2018 at 2:11 PM Ilias Tsoumas  wrote:
>
>> Hi Merlijn,
>>
>> First of all thank you for your quick and essential answer!
>>
>> Reply inline
>>
>> Great to hear you're doing cool stuff with Juju! I recently asked a
>>> similar question for a paper I've written for CLOUD 2018
>>> https://lists.ubuntu.com/archives/juju/2018-January/009845.html. If you
>>> want, I can send it to you in private (it's accepted but not published yet).
>>>
>>
>> Of course. I would like to read your paper. Also me and a colleague work
>> on performance estimations of app components (=charms). If I have suspected
>> properly your paper is related with performance analysis/profiling thus it
>> will be inspiration for us.
>>
>> Here is the documentation for the charm store api:
>>> https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md
>>>
>>
>> I will check it.
>>
>> Here is an Jupyter notebook I use to get metrics of charm and layer
>>> usage:
>>> https://github.com/IBCNServices/reactive-pattern-results/blob/master/reactive-usage-stats.ipynb.
>>> It should be easy to modify that code to pull info about the bundles. As an
>>> example; this is the URL to get all bundles in the Juju store:
>>> https://api.jujucharms.com/charmstore/v5/list?type=bundle
>>
>>
>> Thank you! I hope to be feasible to pull all bundle.yaml with one
>> query/request.
>>
>> BR,
>> Ilias
>>
>> On Mon, Jun 4, 2018 at 3:22 PM Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Hi Ilias
>>>
>>>
>>> Great to hear you're doing cool stuff with Juju! I recently asked a
>>> similar question for a paper I've written for CLOUD 2018
>>> https://lists.ubuntu.com/archives/juju/2018-January/009845.html. If you
>>> want, I can send it to you in private (it's accepted but not published yet).
>>>
>>> Here is the documentation for the charm store api:
>>> https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md
>>>
>>>- download the entire zip for a bundle:
>>>https://api.

Re: adding nics to a vm in vmware built by juju deploy

[Merlijn Sebrechts]

That's strange, I can edit any juju-created VM, as long as I shut it down
first. I can add extra interfaces and change ram, cpu and disk.

Op di 19 jun. 2018 om 15:24 schreef Daniel Bidwell :

> Our VMWare Vcenter is running version 6.5.  There are 2 sets of tools,
> one in flash which is supposed to be going away and one in html5.  The
> html5 version doesn't support all of the features it needs to yet.  The
> html5 views the juju created vms as locked, but the flash version
> allows us to edit them as needed.
>
> We work with the tools that are available and throw out ideas for
> features that would improve it.
>
> Love the juju tools!  Great work everyone!
>
> On Tue, 2018-06-19 at 08:49 -0400, Rick Harding wrote:
> > I'm not familiar if there's any way to unlock/force through VMWare
> > but Juju doesn't currently support the idea of adding nics to running
> > instances at this moment. It's something we're definitely looking for
> > the future as clouds do support things like hot plugging nics. It
> > might be worth a test to see if you can adjust the nics on the VMWare
> > side. In some cases you can work around Juju like adding storage to
> > the root disk by upgrading the instance through the cloud tooling.
> >
> > On Fri, Jun 8, 2018 at 7:58 AM Daniel Bidwell 
> > wrote:
> > > I have a vmware server that I am using as the target for deploying
> > > vms
> > > with juju.  I have a set of vms that need multiple nics on
> > > different
> > > vlans/vmware networks.  I want the vm to be on the primary network,
> > > but
> > > also have nics for 4 other secondary networks.
> > >
> > > Once the vm is deployed, vmware considers it locked and will not
> > > let me
> > > add additional nics.  Is there a way to unlock it?  Or is there a
> > > way
> > > to deploy the vm with the nics installed from the start?
> > >
> > > I didn't see anything in the online docs about adding additional
> > > networks to the constraints clause of the deploy.  If this feature
> > > is
> > > not available at this time, could it be considered for the future?
> > > --
> > > Daniel Bidwell 
> > >
> > >
> > >
> --
> Daniel Bidwell 
>
>
> --
> 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

Re: adding nics to a vm in vmware built by juju deploy

[Merlijn Sebrechts]

*Note: this is with the flash UI.*

Op do 21 jun. 2018 om 14:53 schreef Merlijn Sebrechts <
merlijn.sebrec...@gmail.com>:

> That's strange, I can edit any juju-created VM, as long as I shut it down
> first. I can add extra interfaces and change ram, cpu and disk.
>
> Op di 19 jun. 2018 om 15:24 schreef Daniel Bidwell :
>
>> Our VMWare Vcenter is running version 6.5.  There are 2 sets of tools,
>> one in flash which is supposed to be going away and one in html5.  The
>> html5 version doesn't support all of the features it needs to yet.  The
>> html5 views the juju created vms as locked, but the flash version
>> allows us to edit them as needed.
>>
>> We work with the tools that are available and throw out ideas for
>> features that would improve it.
>>
>> Love the juju tools!  Great work everyone!
>>
>> On Tue, 2018-06-19 at 08:49 -0400, Rick Harding wrote:
>> > I'm not familiar if there's any way to unlock/force through VMWare
>> > but Juju doesn't currently support the idea of adding nics to running
>> > instances at this moment. It's something we're definitely looking for
>> > the future as clouds do support things like hot plugging nics. It
>> > might be worth a test to see if you can adjust the nics on the VMWare
>> > side. In some cases you can work around Juju like adding storage to
>> > the root disk by upgrading the instance through the cloud tooling.
>> >
>> > On Fri, Jun 8, 2018 at 7:58 AM Daniel Bidwell 
>> > wrote:
>> > > I have a vmware server that I am using as the target for deploying
>> > > vms
>> > > with juju.  I have a set of vms that need multiple nics on
>> > > different
>> > > vlans/vmware networks.  I want the vm to be on the primary network,
>> > > but
>> > > also have nics for 4 other secondary networks.
>> > >
>> > > Once the vm is deployed, vmware considers it locked and will not
>> > > let me
>> > > add additional nics.  Is there a way to unlock it?  Or is there a
>> > > way
>> > > to deploy the vm with the nics installed from the start?
>> > >
>> > > I didn't see anything in the online docs about adding additional
>> > > networks to the constraints clause of the deploy.  If this feature
>> > > is
>> > > not available at this time, could it be considered for the future?
>> > > --
>> > > Daniel Bidwell 
>> > >
>> > >
>> > >
>> --
>> Daniel Bidwell 
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: adding nics to a vm in vmware built by juju deploy

[Merlijn Sebrechts]

*Note: this is with the flash UI.*

Op do 21 jun. 2018 om 14:53 schreef Merlijn Sebrechts <
merlijn.sebrec...@gmail.com>:

> That's strange, I can edit any juju-created VM, as long as I shut it down
> first. I can add extra interfaces and change ram, cpu and disk.
>
> Op di 19 jun. 2018 om 15:24 schreef Daniel Bidwell :
>
>> Our VMWare Vcenter is running version 6.5.  There are 2 sets of tools,
>> one in flash which is supposed to be going away and one in html5.  The
>> html5 version doesn't support all of the features it needs to yet.  The
>> html5 views the juju created vms as locked, but the flash version
>> allows us to edit them as needed.
>>
>> We work with the tools that are available and throw out ideas for
>> features that would improve it.
>>
>> Love the juju tools!  Great work everyone!
>>
>> On Tue, 2018-06-19 at 08:49 -0400, Rick Harding wrote:
>> > I'm not familiar if there's any way to unlock/force through VMWare
>> > but Juju doesn't currently support the idea of adding nics to running
>> > instances at this moment. It's something we're definitely looking for
>> > the future as clouds do support things like hot plugging nics. It
>> > might be worth a test to see if you can adjust the nics on the VMWare
>> > side. In some cases you can work around Juju like adding storage to
>> > the root disk by upgrading the instance through the cloud tooling.
>> >
>> > On Fri, Jun 8, 2018 at 7:58 AM Daniel Bidwell 
>> > wrote:
>> > > I have a vmware server that I am using as the target for deploying
>> > > vms
>> > > with juju.  I have a set of vms that need multiple nics on
>> > > different
>> > > vlans/vmware networks.  I want the vm to be on the primary network,
>> > > but
>> > > also have nics for 4 other secondary networks.
>> > >
>> > > Once the vm is deployed, vmware considers it locked and will not
>> > > let me
>> > > add additional nics.  Is there a way to unlock it?  Or is there a
>> > > way
>> > > to deploy the vm with the nics installed from the start?
>> > >
>> > > I didn't see anything in the online docs about adding additional
>> > > networks to the constraints clause of the deploy.  If this feature
>> > > is
>> > > not available at this time, could it be considered for the future?
>> > > --
>> > > Daniel Bidwell 
>> > >
>> > >
>> > >
>> --
>> Daniel Bidwell 
>>
>>
>> --
>> 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

Re: adding nics to a vm in vmware built by juju deploy

[Merlijn Sebrechts]

That's strange, I can edit any juju-created VM, as long as I shut it down
first. I can add extra interfaces and change ram, cpu and disk.

Op di 19 jun. 2018 om 15:24 schreef Daniel Bidwell :

> Our VMWare Vcenter is running version 6.5.  There are 2 sets of tools,
> one in flash which is supposed to be going away and one in html5.  The
> html5 version doesn't support all of the features it needs to yet.  The
> html5 views the juju created vms as locked, but the flash version
> allows us to edit them as needed.
>
> We work with the tools that are available and throw out ideas for
> features that would improve it.
>
> Love the juju tools!  Great work everyone!
>
> On Tue, 2018-06-19 at 08:49 -0400, Rick Harding wrote:
> > I'm not familiar if there's any way to unlock/force through VMWare
> > but Juju doesn't currently support the idea of adding nics to running
> > instances at this moment. It's something we're definitely looking for
> > the future as clouds do support things like hot plugging nics. It
> > might be worth a test to see if you can adjust the nics on the VMWare
> > side. In some cases you can work around Juju like adding storage to
> > the root disk by upgrading the instance through the cloud tooling.
> >
> > On Fri, Jun 8, 2018 at 7:58 AM Daniel Bidwell 
> > wrote:
> > > I have a vmware server that I am using as the target for deploying
> > > vms
> > > with juju.  I have a set of vms that need multiple nics on
> > > different
> > > vlans/vmware networks.  I want the vm to be on the primary network,
> > > but
> > > also have nics for 4 other secondary networks.
> > >
> > > Once the vm is deployed, vmware considers it locked and will not
> > > let me
> > > add additional nics.  Is there a way to unlock it?  Or is there a
> > > way
> > > to deploy the vm with the nics installed from the start?
> > >
> > > I didn't see anything in the online docs about adding additional
> > > networks to the constraints clause of the deploy.  If this feature
> > > is
> > > not available at this time, could it be considered for the future?
> > > --
> > > Daniel Bidwell 
> > >
> > >
> > >
> --
> Daniel Bidwell 
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Please promulgate Mattermost charm

[Merlijn Sebrechts]

Isn't riot a matrix client application?

When I started looking into a slack replacement, matrix just didn't seem
there yet, and it wasn't clear whether it was even going to make it, so I
chose Mattermost because it seemed like the best choice out of all the
competitors: good codebase, good test suite, incredible documentation,
easy-to-understand ecosystem and the company has a clear business model.

Now that Matrix is getting more traction, and seeing as they are getting
financial independence, I'd really like to see if we can integrate
Mattermost into Matrix more.



On Sun, 17 Jun 2018, 16:26 Marco Ceppi,  wrote:

> Do you also have a riot charm? If not I'd be interested in helping author
> one.
>
> On Sat, Jun 16, 2018, 19:31 Merlijn Sebrechts 
> wrote:
>
>> Hi all
>>
>>
>> I created a Charm for Mattermost based on Casey's initial proof of
>> concept. I've been using it for more than a year now to host a Mattermost
>> instance for our local hackerspace. I can highly recommend the application,
>> it's a worthy Slack alternative!
>>
>> So, hereby my -better-late-than-never- request to promulgate the charm.
>>
>> https://jujucharms.com/u/tengu-team/mattermost/
>>
>> The charm supports both http and https traffic (with a lets encrypt
>> certificate that gets automatically renewed) and stores its data (encrypted
>> at rest) in PostgreSQL.
>>
>>
>>
>> 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

Please promulgate Mattermost charm

[Merlijn Sebrechts]

Hi all


I created a Charm for Mattermost based on Casey's initial proof of concept.
I've been using it for more than a year now to host a Mattermost instance
for our local hackerspace. I can highly recommend the application, it's a
worthy Slack alternative!

So, hereby my -better-late-than-never- request to promulgate the charm.

https://jujucharms.com/u/tengu-team/mattermost/

The charm supports both http and https traffic (with a lets encrypt
certificate that gets automatically renewed) and stores its data (encrypted
at rest) in PostgreSQL.



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

Re: Aggregate all bundle.yaml | API endpoint

[Merlijn Sebrechts]

Hi Ilias


Great to hear you're doing cool stuff with Juju! I recently asked a similar
question for a paper I've written for CLOUD 2018
https://lists.ubuntu.com/archives/juju/2018-January/009845.html. If you
want, I can send it to you in private (it's accepted but not published yet).

Here is the documentation for the charm store api:
https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md

   - download the entire zip for a bundle:
   https://api.jujucharms.com/charmstore/v5/bundle//archive
   - download a specific file of a bundle:
   
https://api.jujucharms.com/charmstore/v5/bundle//archive/bundle.yaml

Here is an Jupyter notebook I use to get metrics of charm and layer usage:
https://github.com/IBCNServices/reactive-pattern-results/blob/master/reactive-usage-stats.ipynb.
It should be easy to modify that code to pull info about the bundles. As an
example; this is the URL to get all bundles in the Juju store:
https://api.jujucharms.com/charmstore/v5/list?type=bundle

Cleaning up the data will be the hard part probably, since there are a lot
of unused/broken bundles in the store. I've used the downloads/month metric
to figure out what charms are actually still used.

Op ma 4 jun. 2018 om 14:05 schreef Ilias Tsoumas :

> Hello all,
>
> I have designed and I am developing a novel recommender system which will
> provide recommendations at application graph (=bundle) composition time.
> Now I need a real graphs dataset. I think that all juju bundles of
> components is a good real dataset. Are there some how to aggregate all
> these "bundle.yaml" files? Are there some api endpoint?
> This work is funding from the European Union’s Horizon 2020 research and
> innovation program under grant agreement No 761898 project Matilda.
>
> Kind regards,
> Ilias Tsoumas
> --
> 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: Should 'juju status' always include a timestamp

[Merlijn Sebrechts]

+1

Op wo 18 apr. 2018 om 09:19 schreef John A Meinel :

> I was just going over a list of pastes from James Beedy on this bug:
>   https://bugs.launchpad.net/juju/+bug/1763963
>
> And I realized that something that would be really nice is to just have
> some sort of timestamp so you could see how much time elapsed between each
> "juju status". And given the use of 'juju status' it seems like something
> that would generally be useful. (sharing a snapshot with someone else would
> always be done with the context of *when* you ran that status, so you could
> correlate it with other information like load metrics, etc.)
>
> Thoughts? It seems easy enough to add, but do people feel that it
> does/doesn't belong?
>
> John
> =:->
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Fwd: charms.reactive 0.6.1

[Merlijn Sebrechts]

Hi all


Sending this email because I really like the new Endpoints pattern and
because Cory is underselling the changes of this release. 

This version adds the `all_departed_units
`
collection: a list of all units that have departed. The list is persistent
and mutable, so a handler can use this list to keep track of which departed
units still have to be cleaned up. Each time a unit is cleaned up, the
handler removes that unit from `all_departed_units`, and this removal will
be persisted.


An example: you need to run a command each time a unit departs the relation.

@when('endpoint.{endpoint_name}.departed')
def handle_departed_unit(self):
for name, unit in self.departed_units.items():
# run the command to remove `unit` from the cluster
# ..
self.departed_units.clear()
clear_flag(self.expand_name('departed'))


This is how the flags relate

[image: Inline afbeelding 1]

Basically, the "joined" flag represents the state of the relationship and
will be automatically cleared when all units are gone. "changed" and
"departed" represents relationship events and have to be cleared manually
by the handler

This is a good example of why we switched from "state" to "flag": 'changed'
and 'departed' make no sense as a state, they are events that need to be
handled.



Regards
Merlijn


2018-02-20 22:21 GMT+01:00 Cory Johns :

> Greetings,
>
> Today we released version 0.6.1 of charms.reactive.  The full changelog
> can be found at https://charmsreactive.readthedocs.io/en/latest/changelog
> .html with the changes from this release being:
>
> * Separate departed units from joined in Endpoint (#153)
> * Add deprecated placeholder for RelationBase.from_state (#148)
>
> --
> 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

Critical regression on vsphere due to cloud-init

[Merlijn Sebrechts]

Hi all


I want to bring a critical regression on vsphere to your attention. DNS on
vsphere recently got broken, probably due to a regression in cloud-init.
Link to the bug report below. Because of this, we're unable to deploy many
bundles such as the big data bundles and the Kubernetes bundles.

Is somebody working on a fix? The CDK issue mentions a workaround; does
anybode know what that workaround is?

- Bug in cloud-init: https://bugs.launchpad.net/cloud-init/+bug/1746455
- Bug in CDK:
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/480
- Someone on askubuntu having the same issue:
https://askubuntu.com/questions/994629/dhcp-lease-always-registered-with-default-ubuntu-instead-of-actual-hostname-at



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

Critical regression on vsphere due to cloud-init

[Merlijn Sebrechts]

Hi all


I want to bring a critical regression on vsphere to your attention. DNS on
vsphere recently got broken, probably due to a regression in cloud-init.
Link to the bug report below. Because of this, we're unable to deploy many
bundles such as the big data bundles and the Kubernetes bundles.

Is somebody working on a fix? The CDK issue mentions a workaround; does
anybode know what that workaround is?

- Bug in cloud-init: https://bugs.launchpad.net/cloud-init/+bug/1746455
- Bug in CDK:
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/480
- Someone on askubuntu having the same issue:
https://askubuntu.com/questions/994629/dhcp-lease-always-registered-with-default-ubuntu-instead-of-actual-hostname-at



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

Re: Statistics and metrics about Charm, layer and interface usage

[Merlijn Sebrechts]

Awesome! Thanks guys!

2018-01-25 17:38 GMT+01:00 Rick Harding <rick.hard...@canonical.com>:

> https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md is the
> docs for the API to the charmstore itself. As Adam notes, you can pull down
> any file and there's manifest call that lists out the files in the charm.
> From there you could probably check if the charm has a layers.yaml and if
> so fetch that file, parse it, etc.
>
> https://github.com/juju/charmstore/blob/v5-unstable/
> docs/API.md#get-idmetamanifest
>
> On Thu, Jan 25, 2018 at 11:22 AM Adam Collard <adam.coll...@canonical.com>
> wrote:
>
>> Hi Merlijn,
>>
>>
>> On Thu, 25 Jan 2018 at 16:17 Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Hi all
>>>
>>>
>>> I'm writing a Juju-related paper and I'd like to get statistics
>>> on Charm, layer and interface usage. Are these publicly available?
>>>
>>> Related: is there a documented API to get the code of the charms that
>>> are available in the charm store?
>>>
>>
>> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/
>> will give you a .zip
>> and
>>
>> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/
>> archive/$PATH/$TO/$FILE
>> will give you the 'raw' contents.
>>
>> e.g. curl https://api.jujucharms.com/charmstore/v5/postgresql/
>> archive/hooks/install
>>
>> YMMV,
>>
>> Adam
>> --
>> 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

Re: Statistics and metrics about Charm, layer and interface usage

[Merlijn Sebrechts]

Awesome! Thanks guys!

2018-01-25 17:38 GMT+01:00 Rick Harding <rick.hard...@canonical.com>:

> https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md is the
> docs for the API to the charmstore itself. As Adam notes, you can pull down
> any file and there's manifest call that lists out the files in the charm.
> From there you could probably check if the charm has a layers.yaml and if
> so fetch that file, parse it, etc.
>
> https://github.com/juju/charmstore/blob/v5-unstable/
> docs/API.md#get-idmetamanifest
>
> On Thu, Jan 25, 2018 at 11:22 AM Adam Collard <adam.coll...@canonical.com>
> wrote:
>
>> Hi Merlijn,
>>
>>
>> On Thu, 25 Jan 2018 at 16:17 Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Hi all
>>>
>>>
>>> I'm writing a Juju-related paper and I'd like to get statistics
>>> on Charm, layer and interface usage. Are these publicly available?
>>>
>>> Related: is there a documented API to get the code of the charms that
>>> are available in the charm store?
>>>
>>
>> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/
>> will give you a .zip
>> and
>>
>> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/
>> archive/$PATH/$TO/$FILE
>> will give you the 'raw' contents.
>>
>> e.g. curl https://api.jujucharms.com/charmstore/v5/postgresql/
>> archive/hooks/install
>>
>> YMMV,
>>
>> Adam
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju-dev
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Statistics and metrics about Charm, layer and interface usage

[Merlijn Sebrechts]

Hi all


I'm writing a Juju-related paper and I'd like to get statistics on Charm,
layer and interface usage. Are these publicly available?

Related: is there a documented API to get the code of the charms that are
available in the charm store?



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

Statistics and metrics about Charm, layer and interface usage

[Merlijn Sebrechts]

Hi all


I'm writing a Juju-related paper and I'd like to get statistics on Charm,
layer and interface usage. Are these publicly available?

Related: is there a documented API to get the code of the charms that are
available in the charm store?



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

Re: Juju 2.3.0 is here!

[Merlijn Sebrechts]

Slightly related; is there a way to update _all_ models on a controller
with one command?

2017-12-08 10:14 GMT+01:00 Andrew Wilkins :

> On Fri, Dec 8, 2017 at 6:59 AM Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
>> The Juju team are extremely pleased to announce the release of Juju 2.3.
>> Juju is now more versatile, more efficient, and more configurable than ever.
>>
>> Cross Model Relations deliver a new way of organising your software
>> stack. Deploy a database in one model and connect it to an application
>> running another, even one running on a different controller, or even a
>> different cloud.
>>
>> For containers at scale, Juju now integrates Canonical's Fan overlay
>> network system. This allows containers to map network traffic to any other
>> container on the fan network without distributed databases, consensus
>> protocols, or any extra overhead.
>>
>> Juju's support for bundles has made it possible to quickly deploy
>> connected sets of applications for some time now, but no two use cases are
>> the same. That's why we have introduced the concept of an 'overlay' bundle
>> - now you can easily add your own configuration and tweaks to a bundle at
>> deploy time. See below for links to more information on this and other key
>> features.
>>
>
> Hi folks,
>
> Unfortunately a critical bug [0] has escaped to the field. This bug
> affects existing relations in upgraded models. Models created after
> upgrading, or with a fresh bootstrap, or where relations are created after
> upgrading, will not be affected.
>
> I would not recommend upgrading from 2.x. to 2.3.0. We will be working on
> a fix for 2.3.1, and I expect this issue will bring that release forward
> much sooner. If you have already upgraded and are affected, then you can
> fix it by adding a document to the "statuses" collection in Mongo, as
> described in the bug.
>
> Cheers,
> Andrew
>
> [0] https://bugs.launchpad.net/juju/+bug/1737107
>
>
>>
>>
>> ## How can I get it?
>>
>>
>> The best way to get your hands on this release of Juju is to install it
>> via snap packages (see https://snapcraft.io/for more info on snaps).
>>
>>
>>snap install juju --classic
>>
>>
>> Other packages are available for a variety of platforms. Please see the
>> online documentation at https://jujucharms.com/docs/2.3/reference-install
>>  . Those
>> subscribed to a snap channel should be automatically upgraded. If you’re
>> using the ppa/homebrew, you should see an upgrade available.
>>
>>
>> For highlights of this release, please see the documentation at
>>
>> https://jujucharms.com/docs/2.3/whats-new. Further details are below.
>>
>>
>>
>> ## New
>>
>>
>> * Cross Model Relations:
>>
>>  - see https://jujucharms.com/docs/2.3/models-cmr
>>
>>
>> * Persistent Storage:
>>
>>  - see https://jujucharms.com/docs/2.3/charms-storage
>>
>>
>> * FAN:
>>
>>  - see https://jujucharms.com/docs/2.3/charms-fan
>>
>>
>> * Bundle deployments:
>>
>>  - Changed flags for deploying bundles to existing machines
>>
>>  - Bundle deploy flag --bundle-config replaced with --overlay
>>
>>  - Deploying bundles now supports --dry-run
>>
>>  - Deploying bundles can now target existing machines
>>
>>
>> * Update Application Series:
>>
>>  - see https://jujucharms.com/docs/2.3/howto-updateseries
>>
>>
>> * Parallelization of the Machine Provisioner:
>>
>> - Groups of machines will now be provisioned in parallel reducing
>> deployment time, especially on large bundles.
>>
>>
>> * open_port and close_port hook tools now support ICMP
>>
>> - The open_port and close_port hook tools now support opening firewall
>> access for ICMP. The syntax is:
>>
>> open_port icmp
>>
>>
>> * LXD Storage Provider:
>>
>>  - see https://jujucharms.com/docs/2.3/charms-storage#lxd-(lxd)
>>
>>
>> ## Fixes
>>
>>
>> * Listing of Juju models is more efficient and can now handle more models
>> gracefully
>>
>> * Leadership coordinations is no longer tied to local time which avoids
>> problems with clock skew and reduces overall load on the database
>>
>> * Models are now more reliably destroyed and several fixes to avoid
>> negative impacts while they are being removed
>>
>>
>> You can check the milestones for a detailed breakdown of the Juju bugs we
>> have fixed:
>>
>>
>> https://launchpad.net/juju/+milestone/2.3.0
>>
>> https://launchpad.net/juju/+milestone/2.3-rc2
>>
>> https://launchpad.net/juju/+milestone/2.3-rc1
>>
>> https://launchpad.net/juju/+milestone/2.3-beta3
>>
>> https://launchpad.net/juju/+milestone/2.3-beta2
>>
>> https://launchpad.net/juju/+milestone/2.3-beta1
>>
>>
>>
>> ## Known issues
>>
>> The issues are targeted to be addressed in the upcoming 2.3.1 release.
>>
>>
>> * Firewaller issues on vmware vsphere https://bugs.
>> launchpad.net/juju/+bug/1732665
>>
>>
>> * LXD broken on vmware
>> https://bugs.launchpad.net/juju/+bug/1733882
>>
>>
>> * Can't deploy bundle with map-machines=existing and 

Re: Juju 2.3.0 is here!

[Merlijn Sebrechts]

Slightly related; is there a way to update _all_ models on a controller
with one command?

2017-12-08 10:14 GMT+01:00 Andrew Wilkins :

> On Fri, Dec 8, 2017 at 6:59 AM Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
>> The Juju team are extremely pleased to announce the release of Juju 2.3.
>> Juju is now more versatile, more efficient, and more configurable than ever.
>>
>> Cross Model Relations deliver a new way of organising your software
>> stack. Deploy a database in one model and connect it to an application
>> running another, even one running on a different controller, or even a
>> different cloud.
>>
>> For containers at scale, Juju now integrates Canonical's Fan overlay
>> network system. This allows containers to map network traffic to any other
>> container on the fan network without distributed databases, consensus
>> protocols, or any extra overhead.
>>
>> Juju's support for bundles has made it possible to quickly deploy
>> connected sets of applications for some time now, but no two use cases are
>> the same. That's why we have introduced the concept of an 'overlay' bundle
>> - now you can easily add your own configuration and tweaks to a bundle at
>> deploy time. See below for links to more information on this and other key
>> features.
>>
>
> Hi folks,
>
> Unfortunately a critical bug [0] has escaped to the field. This bug
> affects existing relations in upgraded models. Models created after
> upgrading, or with a fresh bootstrap, or where relations are created after
> upgrading, will not be affected.
>
> I would not recommend upgrading from 2.x. to 2.3.0. We will be working on
> a fix for 2.3.1, and I expect this issue will bring that release forward
> much sooner. If you have already upgraded and are affected, then you can
> fix it by adding a document to the "statuses" collection in Mongo, as
> described in the bug.
>
> Cheers,
> Andrew
>
> [0] https://bugs.launchpad.net/juju/+bug/1737107
>
>
>>
>>
>> ## How can I get it?
>>
>>
>> The best way to get your hands on this release of Juju is to install it
>> via snap packages (see https://snapcraft.io/for more info on snaps).
>>
>>
>>snap install juju --classic
>>
>>
>> Other packages are available for a variety of platforms. Please see the
>> online documentation at https://jujucharms.com/docs/2.3/reference-install
>>  . Those
>> subscribed to a snap channel should be automatically upgraded. If you’re
>> using the ppa/homebrew, you should see an upgrade available.
>>
>>
>> For highlights of this release, please see the documentation at
>>
>> https://jujucharms.com/docs/2.3/whats-new. Further details are below.
>>
>>
>>
>> ## New
>>
>>
>> * Cross Model Relations:
>>
>>  - see https://jujucharms.com/docs/2.3/models-cmr
>>
>>
>> * Persistent Storage:
>>
>>  - see https://jujucharms.com/docs/2.3/charms-storage
>>
>>
>> * FAN:
>>
>>  - see https://jujucharms.com/docs/2.3/charms-fan
>>
>>
>> * Bundle deployments:
>>
>>  - Changed flags for deploying bundles to existing machines
>>
>>  - Bundle deploy flag --bundle-config replaced with --overlay
>>
>>  - Deploying bundles now supports --dry-run
>>
>>  - Deploying bundles can now target existing machines
>>
>>
>> * Update Application Series:
>>
>>  - see https://jujucharms.com/docs/2.3/howto-updateseries
>>
>>
>> * Parallelization of the Machine Provisioner:
>>
>> - Groups of machines will now be provisioned in parallel reducing
>> deployment time, especially on large bundles.
>>
>>
>> * open_port and close_port hook tools now support ICMP
>>
>> - The open_port and close_port hook tools now support opening firewall
>> access for ICMP. The syntax is:
>>
>> open_port icmp
>>
>>
>> * LXD Storage Provider:
>>
>>  - see https://jujucharms.com/docs/2.3/charms-storage#lxd-(lxd)
>>
>>
>> ## Fixes
>>
>>
>> * Listing of Juju models is more efficient and can now handle more models
>> gracefully
>>
>> * Leadership coordinations is no longer tied to local time which avoids
>> problems with clock skew and reduces overall load on the database
>>
>> * Models are now more reliably destroyed and several fixes to avoid
>> negative impacts while they are being removed
>>
>>
>> You can check the milestones for a detailed breakdown of the Juju bugs we
>> have fixed:
>>
>>
>> https://launchpad.net/juju/+milestone/2.3.0
>>
>> https://launchpad.net/juju/+milestone/2.3-rc2
>>
>> https://launchpad.net/juju/+milestone/2.3-rc1
>>
>> https://launchpad.net/juju/+milestone/2.3-beta3
>>
>> https://launchpad.net/juju/+milestone/2.3-beta2
>>
>> https://launchpad.net/juju/+milestone/2.3-beta1
>>
>>
>>
>> ## Known issues
>>
>> The issues are targeted to be addressed in the upcoming 2.3.1 release.
>>
>>
>> * Firewaller issues on vmware vsphere https://bugs.
>> launchpad.net/juju/+bug/1732665
>>
>>
>> * LXD broken on vmware
>> https://bugs.launchpad.net/juju/+bug/1733882
>>
>>
>> * Can't deploy bundle with map-machines=existing and 

Re: Juju 2.3-rc2 is here!

[Merlijn Sebrechts]

2017-12-07 13:33 GMT+01:00 Mark Shuttleworth :

> On 12/06/2017 02:51 PM, Nicholas Skaggs wrote:
> > Is your agent stream set to released per chance?
> >
>


Yes it is. This is weird, why doesn't the controller just take the
agent-stream that it was bootstrapped with?


AttributeFromValue
agent-metadata-url   default ""
agent-stream default released
agent-versionmodel   2.3-rc1.1




> > juju model-config -m controller
> >
> > If so, your client won't see the agent binaries as they aren't in the
> > release stream (2.3 isn't yet released).
>
> I wonder if we can be more user friendly about this.
>
> For example, if we had ONE stream, but the releases were tagged, then in
> this case we could find it, and give a more helpful message like:
>
>   juju upgrade-juju -m controller
>   Version 2.3-rc2 exists but is tagged 'candidate', please use explicit
> --agent-version to proceed
>
>   juju upgrade-juju -m controller --agent-version 2.3-rc2
>   Downloading juju 2.3-rc2.
>
> Does that make sense? Everyone can see the candidate releases, but they
> only get them automatically if they have said they want them.
> Nevertheless it's easy for them to see that the candidate release exists
> and how to get it.
>
>

My knowledge of how these streams work is limited but I actually just
expect the agent stream to be the same as the snap channel by default. This
seems to be the case for bootstrapping: when you install the candidate snap
and bootstrap a controller, the controller is the same version as the snap.
So naturally, I expect `juju upgrade-juju` to upgrade the controller to the
latest beta release.

Using snap channels to select which release you want is very ease and
common. Every "new dev release" email from the Juju team explains how to
install the dev release using snap channels..



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

Re: Juju 2.3-rc2 is here!

[Merlijn Sebrechts]

2017-12-07 13:33 GMT+01:00 Mark Shuttleworth :

> On 12/06/2017 02:51 PM, Nicholas Skaggs wrote:
> > Is your agent stream set to released per chance?
> >
>


Yes it is. This is weird, why doesn't the controller just take the
agent-stream that it was bootstrapped with?


AttributeFromValue
agent-metadata-url   default ""
agent-stream default released
agent-versionmodel   2.3-rc1.1




> > juju model-config -m controller
> >
> > If so, your client won't see the agent binaries as they aren't in the
> > release stream (2.3 isn't yet released).
>
> I wonder if we can be more user friendly about this.
>
> For example, if we had ONE stream, but the releases were tagged, then in
> this case we could find it, and give a more helpful message like:
>
>   juju upgrade-juju -m controller
>   Version 2.3-rc2 exists but is tagged 'candidate', please use explicit
> --agent-version to proceed
>
>   juju upgrade-juju -m controller --agent-version 2.3-rc2
>   Downloading juju 2.3-rc2.
>
> Does that make sense? Everyone can see the candidate releases, but they
> only get them automatically if they have said they want them.
> Nevertheless it's easy for them to see that the candidate release exists
> and how to get it.
>
>

My knowledge of how these streams work is limited but I actually just
expect the agent stream to be the same as the snap channel by default. This
seems to be the case for bootstrapping: when you install the candidate snap
and bootstrap a controller, the controller is the same version as the snap.
So naturally, I expect `juju upgrade-juju` to upgrade the controller to the
latest beta release.

Using snap channels to select which release you want is very ease and
common. Every "new dev release" email from the Juju team explains how to
install the dev release using snap channels..



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

Re: Juju 2.3-rc2 is here!

[Merlijn Sebrechts]

I tried this but I get the error that no agent binaries are found? I can
send you the exact error tomorrow, I don't have my laptop with me at the
moment.

On 6 Dec 2017 20:56, "Tim Penhey" <tim.pen...@canonical.com> wrote:

> Hi Merlijn,
>
> You should be able to go:
>   juju upgrade-juju -m controller
>
> That should do the trick. If the client version is different you may
> want to specify the agent version:
>
>   juju upgrade-juju -m controller --agent-version 2.3-rc2
>
> Tim
>
> On 07/12/17 06:26, Merlijn Sebrechts wrote:
> > Is there a way to upgrade a controller from rc1.1 to rc2?
> >
> > 2017-11-29 1:03 GMT+01:00 Nicholas Skaggs <nicholas.ska...@canonical.com
> > <mailto:nicholas.ska...@canonical.com>>:
> >
> > A new release of Juju is here, 2.3-rc2. This is primarily a bug fix
> > release which addresses issues carried over from rc1.
> >
> >
> > ## New and Improved
> >
> >
> > * juju list-models is significantly faster, especially on
> > controllers with large numbers of models
> >
> >
> > * juju no longer records the execution of the update-status hook.
> > This means that you will no longer see 'idle' units move to
> > 'executing' showing 'running update-status hook'. This also means
> > that it isn't recorded in the show-status-log for the unit. As a
> > related item, the squashing of the status-log, which was buggy, has
> > been removed.
> >
> >
> > ## Fixes
> >
> >
> > For a list of all bugs fixed in this release, see
> >
> >
> > https://launchpad.net/juju/+milestone/2.3-rc2
> > <https://launchpad.net/juju/+milestone/2.3-rc2>
> >
> >
> >
> > ## How can I get it?
> >
> >
> > The best way to get your hands on this release of Juju is to install
> > it as a snap package (see https://snapcraft.io/for more info on
> snaps).
> >
> >
> > snap install juju --classic --candidate
> >
> >
> > Other packages are available for a variety of platforms. Please see
> > the online documentation at
> > https://jujucharms.com/docs/stable/reference-install
> > <https://jujucharms.com/docs/stable/reference-install>. Those
> > subscribed to a snap channel should be automatically upgraded. If
> > you’re using the ppa/homebrew, you should see an upgrade available.
> >
> >
> > ## Feedback Appreciated!
> >
> >
> > We encourage everyone to let us know how you're using Juju. Send us a
> >
> > message on Twitter using #jujucharms, join us at #juju on freenode,
> and
> >
> > subscribe to the mailing list at juju@lists.ubuntu.com
> > <mailto:juju@lists.ubuntu.com>.
> >
> >
> > ## More information
> >
> > To learn more about juju please visit https://jujucharms.com.
> >
> > --
> > Juju-dev mailing list
> > juju-...@lists.ubuntu.com <mailto:juju-...@lists.ubuntu.com>
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> > <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

Re: Juju 2.3-rc2 is here!

[Merlijn Sebrechts]

I tried this but I get the error that no agent binaries are found? I can
send you the exact error tomorrow, I don't have my laptop with me at the
moment.

On 6 Dec 2017 20:56, "Tim Penhey" <tim.pen...@canonical.com> wrote:

> Hi Merlijn,
>
> You should be able to go:
>   juju upgrade-juju -m controller
>
> That should do the trick. If the client version is different you may
> want to specify the agent version:
>
>   juju upgrade-juju -m controller --agent-version 2.3-rc2
>
> Tim
>
> On 07/12/17 06:26, Merlijn Sebrechts wrote:
> > Is there a way to upgrade a controller from rc1.1 to rc2?
> >
> > 2017-11-29 1:03 GMT+01:00 Nicholas Skaggs <nicholas.ska...@canonical.com
> > <mailto:nicholas.ska...@canonical.com>>:
> >
> > A new release of Juju is here, 2.3-rc2. This is primarily a bug fix
> > release which addresses issues carried over from rc1.
> >
> >
> > ## New and Improved
> >
> >
> > * juju list-models is significantly faster, especially on
> > controllers with large numbers of models
> >
> >
> > * juju no longer records the execution of the update-status hook.
> > This means that you will no longer see 'idle' units move to
> > 'executing' showing 'running update-status hook'. This also means
> > that it isn't recorded in the show-status-log for the unit. As a
> > related item, the squashing of the status-log, which was buggy, has
> > been removed.
> >
> >
> > ## Fixes
> >
> >
> > For a list of all bugs fixed in this release, see
> >
> >
> > https://launchpad.net/juju/+milestone/2.3-rc2
> > <https://launchpad.net/juju/+milestone/2.3-rc2>
> >
> >
> >
> > ## How can I get it?
> >
> >
> > The best way to get your hands on this release of Juju is to install
> > it as a snap package (see https://snapcraft.io/for more info on
> snaps).
> >
> >
> > snap install juju --classic --candidate
> >
> >
> > Other packages are available for a variety of platforms. Please see
> > the online documentation at
> > https://jujucharms.com/docs/stable/reference-install
> > <https://jujucharms.com/docs/stable/reference-install>. Those
> > subscribed to a snap channel should be automatically upgraded. If
> > you’re using the ppa/homebrew, you should see an upgrade available.
> >
> >
> > ## Feedback Appreciated!
> >
> >
> > We encourage everyone to let us know how you're using Juju. Send us a
> >
> > message on Twitter using #jujucharms, join us at #juju on freenode,
> and
> >
> > subscribe to the mailing list at j...@lists.ubuntu.com
> > <mailto:j...@lists.ubuntu.com>.
> >
> >
> > ## More information
> >
> > To learn more about juju please visit https://jujucharms.com.
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com>
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> > <https://lists.ubuntu.com/mailman/listinfo/juju-dev>
> >
> >
> >
> >
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 2.3-rc2 is here!

[Merlijn Sebrechts]

Is there a way to upgrade a controller from rc1.1 to rc2?

2017-11-29 1:03 GMT+01:00 Nicholas Skaggs :

> A new release of Juju is here, 2.3-rc2. This is primarily a bug fix
> release which addresses issues carried over from rc1.
>
> ## New and Improved
>
> * juju list-models is significantly faster, especially on controllers with
> large numbers of models
>
> * juju no longer records the execution of the update-status hook. This
> means that you will no longer see 'idle' units move to 'executing' showing
> 'running update-status hook'. This also means that it isn't recorded in the
> show-status-log for the unit. As a related item, the squashing of the
> status-log, which was buggy, has been removed.
>
> ## Fixes
>
> For a list of all bugs fixed in this release, see
>
> https://launchpad.net/juju/+milestone/2.3-rc2
>
>
> ## How can I get it?
>
> The best way to get your hands on this release of Juju is to install it as
> a snap package (see https://snapcraft.io/ for more info on snaps).
>
> snap install juju --classic --candidate
>
> Other packages are available for a variety of platforms. Please see the
> online documentation at https://jujucharms.com/docs/
> stable/reference-install. Those subscribed to a snap channel should be
> automatically upgraded. If you’re using the ppa/homebrew, you should see an
> upgrade available.
>
> ## Feedback Appreciated!
>
> We encourage everyone to let us know how you're using Juju. Send us a
>
> message on Twitter using #jujucharms, join us at #juju on freenode, and
>
> subscribe to the mailing list at juju@lists.ubuntu.com.
>
> ## More information
> To learn more about juju please visit https://jujucharms.com.
>
> --
> 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

Re: Juju 2.3-rc2 is here!

[Merlijn Sebrechts]

Is there a way to upgrade a controller from rc1.1 to rc2?

2017-11-29 1:03 GMT+01:00 Nicholas Skaggs :

> A new release of Juju is here, 2.3-rc2. This is primarily a bug fix
> release which addresses issues carried over from rc1.
>
> ## New and Improved
>
> * juju list-models is significantly faster, especially on controllers with
> large numbers of models
>
> * juju no longer records the execution of the update-status hook. This
> means that you will no longer see 'idle' units move to 'executing' showing
> 'running update-status hook'. This also means that it isn't recorded in the
> show-status-log for the unit. As a related item, the squashing of the
> status-log, which was buggy, has been removed.
>
> ## Fixes
>
> For a list of all bugs fixed in this release, see
>
> https://launchpad.net/juju/+milestone/2.3-rc2
>
>
> ## How can I get it?
>
> The best way to get your hands on this release of Juju is to install it as
> a snap package (see https://snapcraft.io/ for more info on snaps).
>
> snap install juju --classic --candidate
>
> Other packages are available for a variety of platforms. Please see the
> online documentation at https://jujucharms.com/docs/
> stable/reference-install. Those subscribed to a snap channel should be
> automatically upgraded. If you’re using the ppa/homebrew, you should see an
> upgrade available.
>
> ## Feedback Appreciated!
>
> We encourage everyone to let us know how you're using Juju. Send us a
>
> message on Twitter using #jujucharms, join us at #juju on freenode, and
>
> subscribe to the mailing list at j...@lists.ubuntu.com.
>
> ## More information
> To learn more about juju please visit https://jujucharms.com.
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Getting the exposed ports

[Merlijn Sebrechts]

Hm, I wonder why the iptables charm is doing that.

from charms.reactive.bus import State

class states(StateList):
connected = State('{relation_name}.connected')
joined = State('{relation_name}.joined')
departed = State('{relation_name}.departed')


The internals of charms.reactive have changed quite a bit in the last few
releases. We kept the public API backwards-compatible, but preventing
breakages when charms dig into the charms.reactive internals is hard..

2017-12-02 23:14 GMT+01:00 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"  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
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Getting the exposed ports

[Merlijn Sebrechts]

Yes, so with juju-run you could run 'opened-ports' in the hook context of
each unit on that machine, and this get all the opened+ports on the machine.

On 2 Dec 2017 04:26, "John Meinel"  wrote:

> I'm pretty sure that opened-ports only reports the ports that Juju had
> opened for the charm that is making the request. I don't think we list all
> ports opened on the machine for all other applications.
>
> So you might need to have a relation that can report it's opened ports to
> the subordinate
>
> John
> =:->
>
> On Dec 1, 2017 20: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"  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
>> 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Getting the exposed ports

[Merlijn Sebrechts]

Maybe somebody has a better way, I think running `opened-ports` using
`juju-run` might do the trick.

2017-12-01 16:51 GMT+01:00 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/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 get started on JAAS with Azure?

[Merlijn Sebrechts]

Hi all


I haven't been able to figure out a non-hacky way to get started on JAAS
with Azure.

What I did currently is to follow all the steps listed here in the docs
[1], cat `~/.local/share/credentials.yaml` and use the Azure credential to
fill in the form in the JAAS UI. This works but there must be an easier
way, no? If not, can we document this workaround so users new to Juju know
how to set it up?




Kind regards
Merlijn

[1] https://jujucharms.com/docs/stable/help-azure
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju patents

[Merlijn Sebrechts]

Hi Mark


The United States Patent Office has an online filing system where you can
submit prior art. <https://patents.meta.stackexchange.com/a/107>

I can help search for prior art, but I have no idea what's actually
required to be valid prior art. The patent application is very dense, and
it's not clear to me what they are claiming. Strangely, TOSCA is referred
to in the patent itself, even though that seems like prior art to me.. Is
anyone in Canonical more familiar with this?



Kind regards
Merlijn

2017-11-15 8:39 GMT+01:00 Mark Shuttleworth <m...@ubuntu.com>:

> On 11/13/2017 09:34 AM, Merlijn Sebrechts wrote:
> > Just got a scholar alert for three patents that seem to be describing
> > Juju/TOSCA.
> >
> > - "TOPOLOGY BASED MANAGEMENT WITH STAGE AND VERSION
> > POLICIES": http://www.freepatentsonline.com/y2017/0302532.html
> > - "TOPOLOGY BASED MANAGEMENT WITH COMPLIANCE
> > POLICIES": http://www.freepatentsonline.com/y2017/0302531.html
> > - TOPOLOGY BASED MANAGEMENT OF SECOND DAY OPERATIONS":
> > http://www.freepatentsonline.com/y2017/0302537.html
> >
> > These were filed in 2014 by HPE. Even with a grace period of one year,
> > it's still more than a year after the first release of Juju and TOSCA.
> > Is Canonical interested in fighting this?
> >
>
> Juju is covered by the Open Invention Network, so I wouldn't expect any
> problems from HPE in this regard. If it's straightforward to notify the
> patent office of prior art, then I'd be happy to facilitate that.
>
> Mark
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

VMWare support in 2.3-rc1.1

[Merlijn Sebrechts]

Hi all


I've been trying out Juju 2.3-rc1.1 on VMware. Good work on this, we were
finally able to create a functional controller on our cluster!

There are however still a couple of issues I wanted to bring to your
attention. The most serious one is that LXD support seems to be broken
(more than on other non-maas clouds).

Our network setup is the following: We have two networks: a
`primary-network`, running a dhcp server with ddns, and a
`external-network` where users need to add an IP address manually. This is
because public ip's are very scarce in our organization and we can't just
give Juju an entire range.

Juju seems to handle this pretty well: when a VM is created, it is attached
to both networks, but it only gets an IP on the `primary-network`. That IP
is then also used as `public-address` for the VM. When a user manually adds
a public IP to the interface, Juju picks that up after a few minutes, and
uses that ip as `public-address`. This is exactly what we want, good job!

These are the issues we're still having:

   - LXD support is broken: with the current network setup, creating an LXD
   container on a VM makes the VM unreachable. If we remove the
   `external-network` from the setup, LXD containers never come up.:
   https://bugs.launchpad.net/juju/+bug/1733882


   - The default constraints VM's differs between EC2/VMware. Is this
   intentional? It causes some bundles to fail since they don't get enough RAM.


   - Firewaller doesn't work: https://bugs.launchpad.net/juju/+bug/1732665


   - cloud-init warns about the cloud being reported as "EC2":
   https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1731868


   - When you remove a VM with Juju, the vmdk disk image is deleted from
   _all_ datastores, instead of only the one where juju put the image. This
   might pose a problem if people use a datastore as a backup.
   https://bugs.launchpad.net/juju/+bug/1733885



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

VMWare support in 2.3-rc1.1

[Merlijn Sebrechts]

Hi all


I've been trying out Juju 2.3-rc1.1 on VMware. Good work on this, we were
finally able to create a functional controller on our cluster!

There are however still a couple of issues I wanted to bring to your
attention. The most serious one is that LXD support seems to be broken
(more than on other non-maas clouds).

Our network setup is the following: We have two networks: a
`primary-network`, running a dhcp server with ddns, and a
`external-network` where users need to add an IP address manually. This is
because public ip's are very scarce in our organization and we can't just
give Juju an entire range.

Juju seems to handle this pretty well: when a VM is created, it is attached
to both networks, but it only gets an IP on the `primary-network`. That IP
is then also used as `public-address` for the VM. When a user manually adds
a public IP to the interface, Juju picks that up after a few minutes, and
uses that ip as `public-address`. This is exactly what we want, good job!

These are the issues we're still having:

   - LXD support is broken: with the current network setup, creating an LXD
   container on a VM makes the VM unreachable. If we remove the
   `external-network` from the setup, LXD containers never come up.:
   https://bugs.launchpad.net/juju/+bug/1733882


   - The default constraints VM's differs between EC2/VMware. Is this
   intentional? It causes some bundles to fail since they don't get enough RAM.


   - Firewaller doesn't work: https://bugs.launchpad.net/juju/+bug/1732665


   - cloud-init warns about the cloud being reported as "EC2":
   https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1731868


   - When you remove a VM with Juju, the vmdk disk image is deleted from
   _all_ datastores, instead of only the one where juju put the image. This
   might pose a problem if people use a datastore as a backup.
   https://bugs.launchpad.net/juju/+bug/1733885



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

promulgate ~tengu-team/openvpn

[Merlijn Sebrechts]

Hi all


~tengu-team/openvpn is a promulgated charm, but I'm not able to push an
update to the store:

$ charm release cs:~tengu-team/openvpn-10
ERROR cannot release charm or bundle: access denied for user
"merlijn-sebrechts"

Can we (tengu-team) get access to that charm? (merlijn-sebrechts is member
of tengu-team)



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

Re: Serverless Model Type

[Merlijn Sebrechts]

+1

With some care, one solution could be used for both containers, serverless
functions and more. We just need two new types of charms:

 - A "platform" charm which connects to the serverless platform and deploys
the function.
 - A "job" charm which describes the function. This is basically a bundle
of metadata.

Connecting the `platform` to the `job` charm will cause a `job-joined` hook
in the platform charm, which can then use `job-get` to get the metadata
describing the function and deploy the function on the platform. This way,
you empower the community to create new "platform" charms for whichever
platforms they see fit: AWS lambda, Kubernetes, Heroku and even Apache
Spark.

 - Juju doesn't need to know the details of each platform because the
connection to the platform is part of the charm.
 - Juju doesn't need to know the details of each "job" type, because the
"job" charm is just a bunch of metadata.

Now add the ability for "job" charms to optionally include relation hooks,
and you can seamlessly connect serverless functions to your existing
infrastructure. Or connect Apache Spark jobs to your existing
infrastructure.

We've created a number of prototypes of this to model and deploy Kubernetes
and Apache Storm topologies in Juju. We used normal charms and relations
for our "platform" and "job" charms. This works really wel, the only issue
is that deploying an entire Juju Agent is wy too much overhead for
modeling a single Docker container, so we would be really happy if Juju
could introduce the idea of "job" charms.



Kind regards
Merlijn




2017-11-16 17:04 GMT+01:00 James Beedy :

> How do people feel about Juju supporting a serverless model type, and
> serverless charm?
>
> Some innovative wrappers popping up that facilitate deploying lambda
> functions:
>   - `serverless deploy` - https://serverless.com/
>   - `zappa deploy` - https://github.com/Miserlou/Zappa
>
> I feel like Juju has the proper constructs needed to support a SL model
> type, and a special SL type charm.
>
> Just an idea, thought I would throw it out there
>
> Thoughts?
>
>
> --
> 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

Re: Serverless Model Type

[Merlijn Sebrechts]

+1

With some care, one solution could be used for both containers, serverless
functions and more. We just need two new types of charms:

 - A "platform" charm which connects to the serverless platform and deploys
the function.
 - A "job" charm which describes the function. This is basically a bundle
of metadata.

Connecting the `platform` to the `job` charm will cause a `job-joined` hook
in the platform charm, which can then use `job-get` to get the metadata
describing the function and deploy the function on the platform. This way,
you empower the community to create new "platform" charms for whichever
platforms they see fit: AWS lambda, Kubernetes, Heroku and even Apache
Spark.

 - Juju doesn't need to know the details of each platform because the
connection to the platform is part of the charm.
 - Juju doesn't need to know the details of each "job" type, because the
"job" charm is just a bunch of metadata.

Now add the ability for "job" charms to optionally include relation hooks,
and you can seamlessly connect serverless functions to your existing
infrastructure. Or connect Apache Spark jobs to your existing
infrastructure.

We've created a number of prototypes of this to model and deploy Kubernetes
and Apache Storm topologies in Juju. We used normal charms and relations
for our "platform" and "job" charms. This works really wel, the only issue
is that deploying an entire Juju Agent is wy too much overhead for
modeling a single Docker container, so we would be really happy if Juju
could introduce the idea of "job" charms.



Kind regards
Merlijn




2017-11-16 17:04 GMT+01:00 James Beedy :

> How do people feel about Juju supporting a serverless model type, and
> serverless charm?
>
> Some innovative wrappers popping up that facilitate deploying lambda
> functions:
>   - `serverless deploy` - https://serverless.com/
>   - `zappa deploy` - https://github.com/Miserlou/Zappa
>
> I feel like Juju has the proper constructs needed to support a SL model
> type, and a special SL type charm.
>
> Just an idea, thought I would throw it out there
>
> Thoughts?
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju patents

[Merlijn Sebrechts]

Hi all


Just got a scholar alert for three patents that seem to be describing
Juju/TOSCA.

- "TOPOLOGY BASED MANAGEMENT WITH STAGE AND VERSION POLICIES":
http://www.freepatentsonline.com/y2017/0302532.html
- "TOPOLOGY BASED MANAGEMENT WITH COMPLIANCE POLICIES":
http://www.freepatentsonline.com/y2017/0302531.html
- TOPOLOGY BASED MANAGEMENT OF SECOND DAY OPERATIONS":
http://www.freepatentsonline.com/y2017/0302537.html

These were filed in 2014 by HPE. Even with a grace period of one year, it's
still more than a year after the first release of Juju and TOSCA. Is
Canonical interested in fighting this?



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

Re: set_state not setting the state immediately

[Merlijn Sebrechts]

2017-10-31 14:39 GMT+01:00 fengxia <fx...@lenovo.com>:

we have been using Ansible (called from charm) for executions.
>


   - Would you recommend this approach to new users?
   - Do you have examples of such Charms?
   - Do you have docs detailing the ansible-Juju integration?
   - What can we do to make this integration easier?



> But ppl fear things they don't understand. Config mgt tools are like
> giving you a set of cooking utensils and a recipe book, you can follow the
> book, or be an iron chef yourself, and surprisingly, many believe they have
> that talent to be the iron chef, though over optimistically often ~~
>

True! I think this one of the reasons why Juju is so successful for
OpenStack. Normal config mgmt tools give you all the control, but it
requires you to completely understand what the deployment scripts are
doing. OpenStack is so complex that it's almost impossible to fully
understand all components so few sysadmins have the knowledge required to
deploy OpenStack with cfg mgmt tools..





>
>

>
>
> On 10/30/2017 11:56 AM, Merlijn Sebrechts wrote:
>
> Hi all
>
>
> Great discussion in this thread. I sense there are two issues here:
>
> 1. The transactional nature of charms.reactive and Juju needs to be
> explained better
> <https://github.com/juju-solutions/charms.reactive/issues/137>. We can't
> change the transactional nature from the charms.reactive side since this is
> a Juju core feature, but we can provide a lot better docs and change
> function names to better match their actual behavior. This is already
> discussed for relationships as part of the Endpoint PR
> <https://github.com/juju-solutions/charms.reactive/pull/123>.
> 2. Idempotency is hard, not commonly understood outside of config mgmt
> community and charms.reactive isn't helping.
> <https://github.com/juju-solutions/charms.reactive/issues/138> Idempotency
> is a solved issue in config mgmt tools. I don't think it's the job of Juju
> and charms.reactive to provide ways to do this because we operate on a
> higher level (service orchestration, not config mgmt). What we should to is
> make it easier to use charms.reactive together with config mgmt tools like
> Puppet and Chef. This will keep us from reinventing the wheel and will
> provide a number of additional benefits (such as being able to leverage
> existing Puppet scripts and quicker charms).
>
> Please create more issues if I've missed something, and add your comments
> to the issues.
>
>
>
> Kind regards
> Merlijn
>
> 2017-10-05 20:50 GMT+02:00 fengxia <fx...@lenovo.com>:
>
>> " An assumption is being made that the state changes get committed
>> immediately, but these changes are actually transactional and
>> following the same transactional behaviour as the Juju hook
>> environment [1]."
>>
>> To chip in my experience as 6-month into learning charms and writing a
>> few simple charms.
>>
>> 1. The "transactional" nature of Juju hook needs better explained. To be
>> honest I have no idea what this means, and what implication it has to a
>> charm writer. Any reference would be helpful.
>>
>> 2. I like Mike Wilson's approach to provide a list of "set_state_xxx"
>> functions so new writer can better guess what this function will do.
>> Further, a different name calls for further study why they are different,
>> thus learning important concept of whatever Juju thinks charm writer needs
>> to understand.
>>
>> Otherwise, I will expect "set_state" will set that state/flag asap. If
>> there is a scanning cycle (which I heard there is some kind of 5-min cycle,
>> which document has not sufficiently made it clear to a writer either),
>> charm writer needs to have better doc to learn what it means for design. I
>> came from embedded system world in which a timer loop is common. It calls
>> for a different thinking than user space script user. I think such
>> implication should be emphasized more.
>>
>> 3. idempotent
>>
>> Again, this is a concept me (or many new writer) will fail to grasp.
>> Looking at "apt install" as example, my reaction was that the package
>> manager is taking care of "doing nothing" if called multiple times. But how
>> this translate to my system in which charm is expected to "do something"?
>> Does it mean I need a gatekeeper like the package manager so to guard these
>> "multiple calls"?
>>
>> Again, this feels like a work around because "set_state" will call the
>> same function block multiple times, which is unintuitive to writer -- when
>> I set a sta

Re: New Endpoints Implementation/New Elasticsearch Charm

[Merlijn Sebrechts]

To be fair, almost all of the implementation work was done by Cory, but the
design of the API was the result of many months of discussion with the core
team.


2017-10-30 11:05 GMT+01:00 James Beedy :

> Whoops srry 
>
> Nice work on this @cory!
>
>  - s/cory/everyone involved/
> On Oct 29, 2017, at 4:30 PM, James Beedy  wrote:
>
> I carved out what seems to be some solid ground on the new Elasticsearch
> rewrite using the new endpoints implementation.
>
> Assuming I'm using this correctly, I found the new endpoints
> implementation to give for a really smooth experience. Nice work on this
> @cory!
>
> Wondering if I could get some feedback on whether I'm actually using it
> correctly, or screwing anything up.
>
> Here are the components
> * Charm github repo - https://github.com/jamesbeedy/layer-elasticsearch
> * host-port interface - https://github.com/jamesbeedy/interface-host-port
> * Elasticsearch charm - https://jujucharms.com/u/
> jamesbeedy/elasticsearch/18
> * Charmstore Bundle - https://jujucharms.com/u/
> jamesbeedy/elasticsearch-non-uniform/2
>
> Deploying ^ bundle should give you http://paste.ubuntu.com/25848402/
>
> Thanks!
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: set_state not setting the state immediately

[Merlijn Sebrechts]

Hi all


Great discussion in this thread. I sense there are two issues here:

1. The transactional nature of charms.reactive and Juju needs to be
explained better
. We can't
change the transactional nature from the charms.reactive side since this is
a Juju core feature, but we can provide a lot better docs and change
function names to better match their actual behavior. This is already
discussed for relationships as part of the Endpoint PR
.
2. Idempotency is hard, not commonly understood outside of config mgmt
community and charms.reactive isn't helping.
 Idempotency
is a solved issue in config mgmt tools. I don't think it's the job of Juju
and charms.reactive to provide ways to do this because we operate on a
higher level (service orchestration, not config mgmt). What we should to is
make it easier to use charms.reactive together with config mgmt tools like
Puppet and Chef. This will keep us from reinventing the wheel and will
provide a number of additional benefits (such as being able to leverage
existing Puppet scripts and quicker charms).

Please create more issues if I've missed something, and add your comments
to the issues.



Kind regards
Merlijn

2017-10-05 20:50 GMT+02:00 fengxia :

> " An assumption is being made that the state changes get committed
> immediately, but these changes are actually transactional and
> following the same transactional behaviour as the Juju hook
> environment [1]."
>
> To chip in my experience as 6-month into learning charms and writing a few
> simple charms.
>
> 1. The "transactional" nature of Juju hook needs better explained. To be
> honest I have no idea what this means, and what implication it has to a
> charm writer. Any reference would be helpful.
>
> 2. I like Mike Wilson's approach to provide a list of "set_state_xxx"
> functions so new writer can better guess what this function will do.
> Further, a different name calls for further study why they are different,
> thus learning important concept of whatever Juju thinks charm writer needs
> to understand.
>
> Otherwise, I will expect "set_state" will set that state/flag asap. If
> there is a scanning cycle (which I heard there is some kind of 5-min cycle,
> which document has not sufficiently made it clear to a writer either),
> charm writer needs to have better doc to learn what it means for design. I
> came from embedded system world in which a timer loop is common. It calls
> for a different thinking than user space script user. I think such
> implication should be emphasized more.
>
> 3. idempotent
>
> Again, this is a concept me (or many new writer) will fail to grasp.
> Looking at "apt install" as example, my reaction was that the package
> manager is taking care of "doing nothing" if called multiple times. But how
> this translate to my system in which charm is expected to "do something"?
> Does it mean I need a gatekeeper like the package manager so to guard these
> "multiple calls"?
>
> Again, this feels like a work around because "set_state" will call the
> same function block multiple times, which is unintuitive to writer -- when
> I set a state, the action for that state is executed once, not over and
> over again until I turn it off. Further, even "remove_state" doesn't take
> effect immediately, so it feels arbitrary how many cycles a block of code
> is executed. This is a design pattern I'm afraid many are not familiar
> with, so some tutorial examples will be much appreciated.
>
> Best,
>
> Feng
>
>
>
>
> On 10/04/2017 08:59 AM, Marco Ceppi wrote:
>
> So, I've not actually checked the logs in a while, but if visibility is an
> issue, it seems reasonable that the reactive framework should print in the
> log that X flags are being reset due to hook failure. Things like
> set_flag_immediate has farther reaching consequences than simply stating
> that flags only get set on success of a hook run.
>
> I know there are further reaching initiatives to alleviate this by
> decoupling the reactive state engine from the juju hooks system. In this
> case each successive loop of the reactive runtime could better snapshot
> state and make failures more granular.
>
> * state is being renamed to flag in the next major version of reactive.
>
> On Wed, Oct 4, 2017 at 8:52 AM Mike Wilson 
> wrote:
>
>> So as a new charm writer coming to Juju I would first do this:
>>
>> def get_ready():
>> func0()
>> func1_fails()
>>
>> Then I would, hopefully, test and notice issues. I would investigate and
>> see that I needed to be idempotent. My next attempt would be to wrap those
>> functions inside state checks with sets after they complete. This would
>> also fail and now the charm creator is left with nothing in the api that
>> can help. They are now off to their own devices to start 

Re: New Endpoints Implementation/New Elasticsearch Charm

[Merlijn Sebrechts]

Some more context:

We're introducing a new way to create interface layers: "Endpoints". You
can see a pre-alpha version in this PR
.

Creating interface layers is currently very tricky and there is a steep
learning curve. Endpoints address those issues, mostly by removing a lot of
"magic" behavior (like SCOPEs), and streamlining interface layers to more
closely resemble normal layers. We're also updating the docs as part of
this process.

Feel free to test it out and let us know what you think of it, but know
that this is an alpha version.


2017-10-30 0:30 GMT+01:00 James Beedy :

> I carved out what seems to be some solid ground on the new Elasticsearch
> rewrite using the new endpoints implementation.
>
> Assuming I'm using this correctly, I found the new endpoints
> implementation to give for a really smooth experience. Nice work on this
> @cory!
>
> Wondering if I could get some feedback on whether I'm actually using it
> correctly, or screwing anything up.
>
> Here are the components
> * Charm github repo - https://github.com/jamesbeedy/layer-elasticsearch
> * host-port interface - https://github.com/jamesbeedy/interface-host-port
> * Elasticsearch charm - https://jujucharms.com/u/
> jamesbeedy/elasticsearch/18
> * Charmstore Bundle - https://jujucharms.com/u/
> jamesbeedy/elasticsearch-non-uniform/2
>
> Deploying ^ bundle should give you http://paste.ubuntu.com/25848402/
>
> Thanks!
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: upgrade-charm hook

[Merlijn Sebrechts]

We're continuing the discussion about this in the charms.reactive issue
tracker: https://github.com/juju-solutions/charms.reactive/issues/87

Feel free to start hacking on this!

2017-10-05 18:37 GMT+02:00 sheila miguez <she...@pobox.com>:

> I'd like something like this.
>
> The layer-snap's upgrade-hook cycle calls code[1] that checks for a
> non-zero resource, and then checks whether that resource has changed. I bet
> many charmers do this, and it would be useful to have a decorator that does
> it for us.
>
>
> [1] https://github.com/stub42/layer-snap/blob/master/lib/
> charms/layer/snap.py#L53
>
>
>
>
> On Tue, Sep 26, 2017 at 9:51 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> That totally does! This sounds like a great path forward that would allow
>> us to eventually migrate away from having 'upgrade-charm' fire when a
>> resource is attached, while maintaining backward compat for the charms that
>> use it until its deprecated.
>>
>> Well  I didn't mean to just imply that things should change to this ^
>> way, but it seems sensible. Possibly we could have more of a conversation
>> around this?
>>
>> ~James
>>
>>
>>
>> On Tue, Sep 26, 2017 at 12:41 AM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Does a `resource.changed` flag address your needs? That should be
>>> possible to implement in charms.reactive, I think.
>>>
>>> 2017-09-24 17:53 GMT+02:00 James Beedy <jamesbe...@gmail.com>:
>>>
>>>> How do people feel about splitting the upgrade-charm hook into multiple
>>>> hooks to facilitate better resource management?
>>>>
>>>> What I'm thinking would be super helpful would be to have the
>>>> upgrade-charm hook still active for charm upgrades, and have separate hooks
>>>> or flags that would indicate resource upgrades.
>>>>
>>>> I'm thinking something like:
>>>>
>>>> 'juju attach myapp myresource=myresource.file'
>>>>
>>>> Would cause the 'upgrade-resource-myresource'  hook to become active on
>>>> instances of 'myapp'.
>>>>
>>>> I feel that having this affinity from resource ->
>>>> resource-upgrade- hook would be a huge win for resource
>>>> management.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Juju-dev mailing list
>>>> juju-...@lists.ubuntu.com
>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>> an/listinfo/juju-dev
>>>>
>>>
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> she...@pobox.com
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: upgrade-charm hook

[Merlijn Sebrechts]

We're continuing the discussion about this in the charms.reactive issue
tracker: https://github.com/juju-solutions/charms.reactive/issues/87

Feel free to start hacking on this!

2017-10-05 18:37 GMT+02:00 sheila miguez <she...@pobox.com>:

> I'd like something like this.
>
> The layer-snap's upgrade-hook cycle calls code[1] that checks for a
> non-zero resource, and then checks whether that resource has changed. I bet
> many charmers do this, and it would be useful to have a decorator that does
> it for us.
>
>
> [1] https://github.com/stub42/layer-snap/blob/master/lib/
> charms/layer/snap.py#L53
>
>
>
>
> On Tue, Sep 26, 2017 at 9:51 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> That totally does! This sounds like a great path forward that would allow
>> us to eventually migrate away from having 'upgrade-charm' fire when a
>> resource is attached, while maintaining backward compat for the charms that
>> use it until its deprecated.
>>
>> Well  I didn't mean to just imply that things should change to this ^
>> way, but it seems sensible. Possibly we could have more of a conversation
>> around this?
>>
>> ~James
>>
>>
>>
>> On Tue, Sep 26, 2017 at 12:41 AM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Does a `resource.changed` flag address your needs? That should be
>>> possible to implement in charms.reactive, I think.
>>>
>>> 2017-09-24 17:53 GMT+02:00 James Beedy <jamesbe...@gmail.com>:
>>>
>>>> How do people feel about splitting the upgrade-charm hook into multiple
>>>> hooks to facilitate better resource management?
>>>>
>>>> What I'm thinking would be super helpful would be to have the
>>>> upgrade-charm hook still active for charm upgrades, and have separate hooks
>>>> or flags that would indicate resource upgrades.
>>>>
>>>> I'm thinking something like:
>>>>
>>>> 'juju attach myapp myresource=myresource.file'
>>>>
>>>> Would cause the 'upgrade-resource-myresource'  hook to become active on
>>>> instances of 'myapp'.
>>>>
>>>> I feel that having this affinity from resource ->
>>>> resource-upgrade- hook would be a huge win for resource
>>>> management.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Juju-dev mailing list
>>>> Juju-dev@lists.ubuntu.com
>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>> an/listinfo/juju-dev
>>>>
>>>
>>>
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> she...@pobox.com
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: upgrade-charm hook

[Merlijn Sebrechts]

Does a `resource.changed` flag address your needs? That should be possible
to implement in charms.reactive, I think.

2017-09-24 17:53 GMT+02:00 James Beedy :

> How do people feel about splitting the upgrade-charm hook into multiple
> hooks to facilitate better resource management?
>
> What I'm thinking would be super helpful would be to have the
> upgrade-charm hook still active for charm upgrades, and have separate hooks
> or flags that would indicate resource upgrades.
>
> I'm thinking something like:
>
> 'juju attach myapp myresource=myresource.file'
>
> Would cause the 'upgrade-resource-myresource'  hook to become active on
> instances of 'myapp'.
>
> I feel that having this affinity from resource ->
> resource-upgrade- hook would be a huge win for resource
> management.
>
> Thoughts?
>
>
>
>
> --
> 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

Re: upgrade-charm hook

[Merlijn Sebrechts]

Does a `resource.changed` flag address your needs? That should be possible
to implement in charms.reactive, I think.

2017-09-24 17:53 GMT+02:00 James Beedy :

> How do people feel about splitting the upgrade-charm hook into multiple
> hooks to facilitate better resource management?
>
> What I'm thinking would be super helpful would be to have the
> upgrade-charm hook still active for charm upgrades, and have separate hooks
> or flags that would indicate resource upgrades.
>
> I'm thinking something like:
>
> 'juju attach myapp myresource=myresource.file'
>
> Would cause the 'upgrade-resource-myresource'  hook to become active on
> instances of 'myapp'.
>
> I feel that having this affinity from resource ->
> resource-upgrade- hook would be a huge win for resource
> management.
>
> Thoughts?
>
>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: charmhelpers migration to github

[Merlijn Sebrechts]

Now I feel stupid about my "delete fork and refork" approach to make sure I
get a clean master for each new PR.. :)

2017-09-21 17:38 GMT+02:00 Alex Kavanagh <alex.kavan...@canonical.com>:

>
>
> On Thu, Sep 21, 2017 at 4:32 PM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> Tracking many upstream projects, I find it most clean to just fetch the
>> the upstream master once my feature branch PR has landed, such that I don't
>> push or merge anything to my own master branch. (Ideally) I only use master
>> branch to sync with upstream and to make new branches from. But that's just
>> me :)
>>
>
> I too, use this approach.  I treat the master as 'pristine' and do all
> work in branches, and if there's an upstream (and there usually is), sync
> that to my master, etc.
>
>
>>
>>
>> > What's the reasoning behind feature branches in private repositories?
>> Why
>> > not just develop on the master of your private repo?
>> >
>> > 2017-09-21 12:12 GMT+02:00 James Hebden <james.heb...@canonical.com>:
>> >
>> >> Just lending my support for Dmitrii's guidance here.
>> >> Clean history is important, especially to those reviewing changes - but
>> >> having a clean history isn't as simple as having a single commit in
>> >> place when merging code from a private branch into upstream - it's
>> >> more important to isolate logical changes into individual branches and
>> >> MP those regularly and without remorse.
>> >> It's a fairly comfortable and obvious distinction - but an important
>> >> one I think when working with MPs.
>> >>
>> >> Reviewing these two commits in one MP -
>> >> "Updated bundled dependencies"
>> >> "Corrected PEP8 errors"
>> >>
>> >> Or one commit
>> >> "Updated bundled dependencies and corrected PEP8 errors"
>> >>
>> >> ...both are going to be a nightmare for the reviewer, especially given
>> >> the GitHub UI's inability to sensibly show changes to a single file
>> when
>> >> a lot of files have changed, especially over multiple commits. Keeping
>> >> MPs short, sweet and logical will make everyone's lives easier when
>> >> working with MPs.
>> >>
>> >> So, If I'm just agreeing with everyone, why am I replying? Well,
>> >> primarily just to point everyone at
>> >> https://github.com/juju/juju/blob/develop/CONTRIBUTING.md#workflow
>> >>
>> >> The existing Juju docs seem to get it right and meet everyone's
>> >> expectation here. Seems like a good candidate for improving the current
>> >> charmhelpers contributing documentation.
>> >>
>> >> Also, thanks for all the hard work to make this happen!
>> >>
>> >>> On Thu, Sep 21, 2017 at 12:35:56PM +0300, Dmitrii Shcherbakov wrote:
>> >>> I think that following the clean history approach is generally good
>> as it
>> >>> makes your life easier during debugging and commit message grepping.
>> >>>
>> >>> Linus' point about
>> >>>
>> >>> https://www.mail-archive.com/dri-devel@lists.sourceforge.
>> >> net/msg39091.html
>> >>> "I want clean history, but that really means (a) clean and (b)
>> history."
>> >>>
>> >>> having both history and keeping it clean is something that we should
>> >>> consider but not enforce too much (subjectively) to avoid making it
>> too
>> >>> hard to commit changes. In the end, this transition to github is about
>> >>> making it easier to contribute, not requiring a person to read a
>> 100-page
>> >>> manual on how to annotate and prepare a commit to push a one-liner.
>> >>>
>> >>> Given that charm-helpers changes are generally small, I think
>> squashing
>> >> is
>> >>> OK even using github's mechanism.
>> >>>
>> >>> For large commits, on the other hand, it makes sense to recreate a
>> pull
>> >>> request (close a PR, update and push to a fork, create a new PR) or
>> >> update
>> >>> an existing PR by doing a complex rebase + force push. When there are
>> >>> several logical changes per commit it is quite important to keep them
>> >>> separate and squashing everything into a single change is essentially
>> >>> hiding his

Re: charmhelpers migration to github

[Merlijn Sebrechts]

What's the reasoning behind feature branches in private repositories? Why
not just develop on the master of your private repo?

2017-09-21 12:12 GMT+02:00 James Hebden <james.heb...@canonical.com>:

> Just lending my support for Dmitrii's guidance here.
> Clean history is important, especially to those reviewing changes - but
> having a clean history isn't as simple as having a single commit in
> place when merging code from a private branch into upstream - it's
> more important to isolate logical changes into individual branches and
> MP those regularly and without remorse.
> It's a fairly comfortable and obvious distinction - but an important
> one I think when working with MPs.
>
> Reviewing these two commits in one MP -
> "Updated bundled dependencies"
> "Corrected PEP8 errors"
>
> Or one commit
> "Updated bundled dependencies and corrected PEP8 errors"
>
> ...both are going to be a nightmare for the reviewer, especially given
> the GitHub UI's inability to sensibly show changes to a single file when
> a lot of files have changed, especially over multiple commits. Keeping
> MPs short, sweet and logical will make everyone's lives easier when
> working with MPs.
>
> So, If I'm just agreeing with everyone, why am I replying? Well,
> primarily just to point everyone at
> https://github.com/juju/juju/blob/develop/CONTRIBUTING.md#workflow
>
> The existing Juju docs seem to get it right and meet everyone's
> expectation here. Seems like a good candidate for improving the current
> charmhelpers contributing documentation.
>
> Also, thanks for all the hard work to make this happen!
>
> On Thu, Sep 21, 2017 at 12:35:56PM +0300, Dmitrii Shcherbakov wrote:
> > I think that following the clean history approach is generally good as it
> > makes your life easier during debugging and commit message grepping.
> >
> > Linus' point about
> >
> > https://www.mail-archive.com/dri-devel@lists.sourceforge.
> net/msg39091.html
> > "I want clean history, but that really means (a) clean and (b) history."
> >
> > having both history and keeping it clean is something that we should
> > consider but not enforce too much (subjectively) to avoid making it too
> > hard to commit changes. In the end, this transition to github is about
> > making it easier to contribute, not requiring a person to read a 100-page
> > manual on how to annotate and prepare a commit to push a one-liner.
> >
> > Given that charm-helpers changes are generally small, I think squashing
> is
> > OK even using github's mechanism.
> >
> > For large commits, on the other hand, it makes sense to recreate a pull
> > request (close a PR, update and push to a fork, create a new PR) or
> update
> > an existing PR by doing a complex rebase + force push. When there are
> > several logical changes per commit it is quite important to keep them
> > separate and squashing everything into a single change is essentially
> > hiding history.
> >
> > An analogy would be file compression: yes, you can squeeze files to a
> > single compressed blob and make it a bit smaller but then you have to
> waste
> > CPU cycles to decode it. In the same way, when you are trying to quickly
> > grep through a git log you don't want to waste brain cycles on decoding
> > unstructured information.
> >
> > Best Regards,
> > Dmitrii Shcherbakov
> >
> > Field Software Engineer
> > IRC (freenode): Dmitrii-Sh
> >
> > On Thu, Sep 21, 2017 at 12:02 PM, Merlijn Sebrechts <
> > merlijn.sebrec...@gmail.com> wrote:
> >
> > > It depends on what you want to optimize the development workflow for. I
> > > think we need to optimize for easiness because a lot of contributors
> will
> > > be ops people who generally have a lot less experience with git and
> github.
> > > I for example have rebased once in my life, and this was only possible
> with
> > > Alex walking me through the process.
> > >
> > > *"Fork to private + PR + dirty fix commits" *is an easy workflow that a
> > > lot of people are familiar with and that works well with Github. If you
> > > want a cleaner commit history, you can always rebase or squash the PR
> > > during merge using the Github UI: https://pasteboard.co/GLmTHnf.png.
> > >
> > > It's not ideal but it's a small price to pay for more contributors..
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2017-09-20 22:10 GMT+02:00 Alex Kavanagh <alex.kavan...@canonical.com
> >:
> > >
> > >> The

Re: Future of the Charm Review Queue

[Merlijn Sebrechts]

Are there any plans to let users assess the "quality" of a charm in a
different way? Like showing the amount of (successful) deploys or smth?

On Aug 4, 2017 16:21, "Tim Van Steenburgh" 
wrote:

> Hi All,
>
> I wanted to send a note about some changes in the way we handle charm
> reviews and the top-level namespace of the charm store. We’ve taken a look
> at what’s happened in the past and where we want to get to and decided that
> a much more lightweight process is the way forward.
>
> The biggest change is actually the sunsetting of the charm review queue.
> The reality is the process as it stands cannot keep up with the demand for
> reviews. We’ve decided to take a community curation approach.
>
> A charm review is no longer a prerequisite for promulgation to the
> top-level namespace of the charm store. If you would like your charm
> promulgated, and the name is available, you may simply request promulgation
> on this mailing list. A member of the ~charmers Launchpad group will then:
>
>
>1.
>
>Download your charm using `charm pull`
>2.
>
>Run `charm proof` on your charm
>3.
>
>Ensure you have `charm set` a bugs-url and homepage
>4.
>
>If 2 or 3 fails, the charmer will request an update to the charm
>5.
>
>`charm promulgate` the charm (or request that #2-3 be fixed)
>6.
>
>`charm grant` you write access on the promulgated charm
>
>
> Some things to keep in mind as a charm author:
>
>
>1.
>
>It is your responsibility as the charm author and maintainer to test
>your charm and ensure its quality and security.
>2.
>
>Promulgation to the top level does not imply endorsement by Canonical.
>3.
>
>Charm authors are encouraged to use their personal or group namespace.
>Although promulgation is still available, there is nothing wrong with using
>personal and group namespaces.
>
>
> For those seeking assistance with charm development, members of ~charmers
> and other proficient charm developers are available in #juju on Freenode
> IRC and on this mailing list. Discontinuing the formal charm review process
> does not in any way decrease the availability of or access to these
> resources. If you need help, just ask!
>
> In the coming weeks, the docs at jujucharms.com will be updated to
> reflect these changes. The review queue (review.jujucharms.com) will be
> shut down, and all open reviews will be closed with a comment/email linking
> to this explanatory post. Anyone with an open review that still desires
> promulgation can request it with an email to this list.
>
> If you have any questions or concerns, please reply to this post!
>
> Thanks,
>
> Tim Van Steenburgh
>
>
> --
> 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

How do upgrades handle resources?

[Merlijn Sebrechts]

Hi all


I'm not sure how resources and upgrades work together. I see that the
kubernetes layers use resources, but you upgrade kubernetes using `juju
upgrade-charm`. How does that work? Does each charm version have a "default
resource" attached?

The resources docs don't really explain this either..
https://jujucharms.com/docs/2.1/developer-resources



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

Re: Juju vs Openshift

[Merlijn Sebrechts]

Juju doesn't have to be responsible for translating the model into the
underlying substrate.

The Charms have always been responsible for interpreting the model. t's the
Charms that figure out what it actually means to "connect Wordpress to
MySQL". This has allowed Charms to become very smart, without adding any
complexity in Juju core.

We should to the same for the workload level, and a process container is
just a workload running on top of a container platform. I created a
proof-of-concept of this here: https://jujucharms.com/u/
tengu-team/limeds-core/

[image: Inline afbeelding 1]

A limeds container running on a Docker engine. The container is sent over
the relationship. It's up to the Docker charm to figure out how to run it.
Now that a docker container is part of the model, we can do a bunch of cool
stuff like connecting loadbalancers, databases and other stuff to the
docker container: https://jujucharms.com/u/tengu-team/limeds-bigdata/

[image: Inline afbeelding 2]

We can swap out the Docker Charm and put Kubernetes in its place because
it's the Charm that decides what it means to run a Docker container. We're
extending Kubernetes with support for this: https://github.com/tengu-team/
layer-kubernetes-deployer

Charmers suddenly get the power to support new container management
platforms such as openshift or swarm. No change in Juju core needed!

I think such an approach is the only way to be able to keep up with the
rapidly changing landscape, because let's be honest, containers
orchestrators aren't the first, nor will they be the last hype. *Any
"assumptions" Juju makes about containers will probably not be true in a
few years time*. Already Kubernetes is creating multiple ways to
dynamically reconfigure containers at runtime... Do we really want to keep
updating Juju core when any of these assumptions change? The only
assumption Juju should make is "I have no idea what to do with this, so
I'll just let the Charms figure it out".

Only a single change in Juju core is needed: create the concept of a
virtual "workload" charm that can communicate with other charms but doesn't
have access to any os.

2017-06-27 14:23 GMT+02:00 Rick Harding :

> I think the reason it's challenging, and that you're seeing different
> tools for different systems, is that each time you want to model something
> you have to make sure you can translate the model into the underlying
> substrates clearly and precisely. To date, Juju hasn't expressed a model on
> the process container world because Juju's model is built upon a set of
> promises that it can make sure each supported substrate can fulfill.
> OpenStack, public cloud, MAAS, etc all have these nice primitive ideas that
> are similar enough that a model can be expressed and then put into place
> onto those different substrates but the promises of the model still hold
> true.
>
> As we've looked at expanding the model to support things like process
> containers there are challenges and opportunities. The immutability of the
> containers breaks a bunch of Juju promises, such as the adaptability when a
> relation is made between applications. There's work that needs to be done
> such that a model can either make clear the differences (say you can model
> applications as well as process containers as different ideas in the model)
> or you need to update and close the gaps between the substrates.
>
> I think you're right on point and that we're aligned on the idea that you
> construct a model of what you want and then allow the system to go and make
> it reality. I think the trouble that we're currently in, and that you're
> finding as you look at options, is that there's a gap at the moment that
> needs to be closed. Folks are trying to say that we're all techies and love
> using the right tool for the right job, and currently there are some things
> that go great into process containers, some things that do better in
> machine containers, and some things that really want to be on raw hardware
> to operate at their best. Over time we hope Juju will expand to help define
> the model across each of those scenarios.
>
> On Tue, Jun 27, 2017 at 12:13 PM Giuseppe Attardi <
> giuseppe.atta...@garr.it> wrote:
>
>> OK, but since I have been asked to help prepare a roadmap for the next 3
>> years for the evolution of cloud services and infrastructure for the
>> Italian public administrations, I need to have both a clear picture of the
>> current situation and to make an educated guess at the most promising
>> technology directions.
>>
>> My feeling is that one should promote a declarative modelling approach to
>> cloud deployment, where one specifies the architecture model he wants to
>> achieve, not how.
>> A workflow engine takes care of generating an actual deployment plan that
>> leads from the current to the desired state.
>> Google director of network architecture, Bikash Koley, explains in this
>> video why they use this approach in managing 

Italian federated cloud runs Juju

[Merlijn Sebrechts]

Hi all


I came accross a paper talking about the Italian GARR federated cloud
, running Juju from the bottom to the
top. It's by the same guy that made one of the Jupyter notebook charms.

A multi-zone MAAS cluster with Juju-deployed OpenStack and Juju on top of
that.

Their website: https://cloud.garr.it/
They're even advertising the bundles on their own website and linking to
the charm store for more applications: https://cloud.garr.it/apps/storage/



Sounds like they're doing cool stuff with Juju, try to get them on the Juju
show!



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

Re: [ANNOUNCEMENT] Virtual Juju Docs Sprint #1

[Merlijn Sebrechts]

Won't be able to make it, but this is a good initiative!

2017-06-16 0:17 GMT+02:00 Adam Israel :

> Hi all,
>
> I'm announcing that we're holding our first Virtual Juju Docs Sprint
> tomorrow from 18-19:00 GMT (14-15:00 EDT). This will be a bi-weekly event
> where developers and users of Juju can get together to work on
> documentation.
>
> When: Jun 16th, at 18:00 GMT, 14:00 EDT
> Where: https://www.youtube.com/watch?v=SKBVtXOXd40
> How to participate: Hang out in the #juju Freenode IRC channel
>
> Join us in the IRC channel to contribute, ask questions, get a link to the
> hangout to join the live stream, or just to listen in on the action. You
> can find details about how you can contribute here:
> https://gist.github.com/AdamIsrael/73e2aadc41c9077712e296c8b7564e9e
>
> Make sure to subscribe to the Juju Youtube channel  so you never miss any
> of the happenings in and around Juju!
>
> https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: [ANNOUNCEMENT] Virtual Juju Docs Sprint #1

[Merlijn Sebrechts]

Won't be able to make it, but this is a good initiative!

2017-06-16 0:17 GMT+02:00 Adam Israel :

> Hi all,
>
> I'm announcing that we're holding our first Virtual Juju Docs Sprint
> tomorrow from 18-19:00 GMT (14-15:00 EDT). This will be a bi-weekly event
> where developers and users of Juju can get together to work on
> documentation.
>
> When: Jun 16th, at 18:00 GMT, 14:00 EDT
> Where: https://www.youtube.com/watch?v=SKBVtXOXd40
> How to participate: Hang out in the #juju Freenode IRC channel
>
> Join us in the IRC channel to contribute, ask questions, get a link to the
> hangout to join the live stream, or just to listen in on the action. You
> can find details about how you can contribute here:
> https://gist.github.com/AdamIsrael/73e2aadc41c9077712e296c8b7564e9e
>
> Make sure to subscribe to the Juju Youtube channel  so you never miss any
> of the happenings in and around Juju!
>
> https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
>
> --
> 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

Re: collecting tips, how-tos, tools used in troubleshooting Juju

[Merlijn Sebrechts]

So, with GCE, there is an issue where Juju isn't able to expose
applications correctly when you use the incorrect credentials. The docs
show to use the "Google compute engine default service account" credential,
but that one isn't available right after creation of a new account/new
project. If you create your own, Juju won't be able to expose applications.

2017-05-24 15:23 GMT+02:00 Rick Harding :

> I'm working to build out the troubleshooting section of the Juju
> documentation. [1] I'd like to collate common issues, tips, scripts, and
> tools folks have buried in wikis, google docs, or their brains. I'd like to
> ask you send anything you've got, as raw an unproofed as it lives today, my
> way. I'll worry about organizing, cleaning up, fine tuning the language,
> etc. I just want to ask everyone to help me brainstorm the things they can
> think of that'll be useful in a full fleshed out troubleshooting guide. No
> issue is too big or too small.
>
> Example useful things that can be generically hit could be I've got X
> configured wrong, or I hit the limit on my cloud compute instances allowed,
> or this is what happens when Y over there goes down.
>
> Potential moving parts to trigger ideas include:
> general help in diagnosing what's going on beyond the logs
> issues getting setup (add-cloud/add-credential) (the rackspace id needs to
> be in quotes)
> errors while bootstrapping
> common issues with deploying, scaling, relations
> issues with sharing/revoking models
> Cloud specific issues and trouble spots
>   - MAAS
>   - LXD
>   - OpenStack
>   - AWS/GCE/Azure
>   - Manual Provider
>
> Items I'm currently calling out of scope include issues around charming as
> I think that's going to be another big chunk with a different enough scope
> to focus on separately.
>
> Thanks for the assistance everyone. From here I'll start to build up a
> "best practices" guide for operating Juju itself and we'll hopefully have a
> lot of useful material going forward that users will be able to self-help
> themselves much more easily.
>
> Rick
>
> 1: https://github.com/juju/docs/pull/1864
>
> --
> 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

Re: collecting tips, how-tos, tools used in troubleshooting Juju

[Merlijn Sebrechts]

So, with GCE, there is an issue where Juju isn't able to expose
applications correctly when you use the incorrect credentials. The docs
show to use the "Google compute engine default service account" credential,
but that one isn't available right after creation of a new account/new
project. If you create your own, Juju won't be able to expose applications.

2017-05-24 15:23 GMT+02:00 Rick Harding :

> I'm working to build out the troubleshooting section of the Juju
> documentation. [1] I'd like to collate common issues, tips, scripts, and
> tools folks have buried in wikis, google docs, or their brains. I'd like to
> ask you send anything you've got, as raw an unproofed as it lives today, my
> way. I'll worry about organizing, cleaning up, fine tuning the language,
> etc. I just want to ask everyone to help me brainstorm the things they can
> think of that'll be useful in a full fleshed out troubleshooting guide. No
> issue is too big or too small.
>
> Example useful things that can be generically hit could be I've got X
> configured wrong, or I hit the limit on my cloud compute instances allowed,
> or this is what happens when Y over there goes down.
>
> Potential moving parts to trigger ideas include:
> general help in diagnosing what's going on beyond the logs
> issues getting setup (add-cloud/add-credential) (the rackspace id needs to
> be in quotes)
> errors while bootstrapping
> common issues with deploying, scaling, relations
> issues with sharing/revoking models
> Cloud specific issues and trouble spots
>   - MAAS
>   - LXD
>   - OpenStack
>   - AWS/GCE/Azure
>   - Manual Provider
>
> Items I'm currently calling out of scope include issues around charming as
> I think that's going to be another big chunk with a different enough scope
> to focus on separately.
>
> Thanks for the assistance everyone. From here I'll start to build up a
> "best practices" guide for operating Juju itself and we'll hopefully have a
> lot of useful material going forward that users will be able to self-help
> themselves much more easily.
>
> Rick
>
> 1: https://github.com/juju/docs/pull/1864
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Migrating charmhelpers to github

[Merlijn Sebrechts]

A big +1!

Launchpad was the reason why I didn't yet contribute to charmhelpers..

2017-05-25 14:57 GMT+02:00 James Page :

> Hi Charmers
>
> There has been a bubbling undercurrent of desire to move charmhelpers code
> hosting out of bazaar on Launchpad to git on github,com alongside other
> charm ecosystem development tooling.
>
> I'd like to get the code migrated over ASAP and then we can start enabling
> automatic PR testing and suchlike which we lack in LP at the moment.
>
> Anyone got any objections?
>
> This will of course impact anyone currently syncing charmhelpers into
> their charm, but that's not a hard problem to solve.
>
> Cheers
>
> James
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PROPOSAL: stop recording 'executing update-status hook'

[Merlijn Sebrechts]

On May 20, 2017 09:05, "John Meinel"  wrote:

I would actually prefer if it shows up in 'juju status' but that we
suppress it from 'juju status-log' by default.


This is still very strange behavior. Why should this be default? Just pipe
the output of juju status through grep and exclude update-status if that is
really what you want.

However, I would even argue that this isn't what you want in most
use-cases.  "update-status" isn't seen as a special hook in
charms.reactive. Anything can happen in that hook if the conditions are
right. Ignoring update-status will have unforeseen consequences...

(*possibly* we could show it with a flag, but I'm not sure that it is worth
tracking or not.)

John
=:->


On Fri, May 19, 2017 at 9:42 PM, Gregory Lutostanski  wrote:

> What would happen if the update-status hook hangs here? I know it only is
> supposed to be for short-duration status messages (but charm bugs are known
> to happen).
>
> In addition, it will also block other hooks/actions from happening until
> completed and it will remain in a stuck state with the status reporting as
> "all good". Is there some middle ground rather than not exposing that the
> unit is working in this situation?
>
> Not to be a nay-sayer just want it more thoroughly looked at from a user's
> least surprise in not-great situations where the deployment is wedged.
>
> We would not know that from the status right? Only from the debug-log.
>
> On May 19, 2017 3:46 AM, "John Meinel"  wrote:
>
>> All agents start up in DEBUG until they can talk to the controller and
>> read what the current logging config is set to. Otherwise you wouldn't be
>> able to debug startup issues.
>> That said, I think there was a request to cache the last-known value in
>> agent.conf which would let restarts be less noisy.
>>
>> John
>> =:->
>>
>>
>> On Fri, May 19, 2017 at 12:23 PM, Samuel Cozannet <
>> samuel.cozan...@canonical.com> wrote:
>>
>>> +1
>>>
>>> Maybe one good thing would also be removing the default --debug flag
>>> from all juju machine startup scripts.
>>> It seems hard coded, and requires edition on most deployment.
>>>
>>> ++
>>> Sam
>>>
>>>
>>> On May 19, 2017 10:12, "Adam Collard" 
>>> wrote:
>>>
>>> On Fri, 19 May 2017 at 03:14 Tim Penhey 
>>> wrote:
>>>
 Hi folks,

 Currently juju will update the status of any hook execution for any unit
 to show that it is busy doing things. This was all well and good until
 we do things based on time.

 Every five minutes (or so) each unit will have the update-status hook
 executed to allow the unit to set or update the workload status based on
 what is currently going on with that unit.

 Since all hook executions are stored, this means that the
 show-status-log will show the unit jumping from executing update-status
 to ready and back every five minutes.

 The proposal is to special case the update-status hook and show in
 status (or the status-log) that the hook is being executed. debug-log
 will continue to show the hook executing if you are looking.

 This will reduce noise in the status-log, simplify some of our code
 around dealing with status-log, and reduce load on controllers looking
 after hundreds or thousands of units.

>>>
>>> +1
>>>
>>>
>>> --
>>> Juju mailing list
>>> j...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> j...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>

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

Re: PROPOSAL: stop recording 'executing update-status hook'

[Merlijn Sebrechts]

Not showing subsequent runs seems very strange behavior as an end user and
will complicate debugging issues with update-status hooks.

Don't remove logs just because they are too verbose, there are use-cases
where this info is needed.


On May 19, 2017 04:14, "Tim Penhey"  wrote:

Hi folks,

Currently juju will update the status of any hook execution for any unit to
show that it is busy doing things. This was all well and good until we do
things based on time.

Every five minutes (or so) each unit will have the update-status hook
executed to allow the unit to set or update the workload status based on
what is currently going on with that unit.

Since all hook executions are stored, this means that the show-status-log
will show the unit jumping from executing update-status to ready and back
every five minutes.

The proposal is to special case the update-status hook and show in status
(or the status-log) that the hook is being executed. debug-log will
continue to show the hook executing if you are looking.

This will reduce noise in the status-log, simplify some of our code around
dealing with status-log, and reduce load on controllers looking after
hundreds or thousands of units.

Is anyone opposed to this change?

Tim

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

Re: PROPOSAL: stop recording 'executing update-status hook'

[Merlijn Sebrechts]

Not showing subsequent runs seems very strange behavior as an end user and
will complicate debugging issues with update-status hooks.

Don't remove logs just because they are too verbose, there are use-cases
where this info is needed.


On May 19, 2017 04:14, "Tim Penhey"  wrote:

Hi folks,

Currently juju will update the status of any hook execution for any unit to
show that it is busy doing things. This was all well and good until we do
things based on time.

Every five minutes (or so) each unit will have the update-status hook
executed to allow the unit to set or update the workload status based on
what is currently going on with that unit.

Since all hook executions are stored, this means that the show-status-log
will show the unit jumping from executing update-status to ready and back
every five minutes.

The proposal is to special case the update-status hook and show in status
(or the status-log) that the hook is being executed. debug-log will
continue to show the hook executing if you are looking.

This will reduce noise in the status-log, simplify some of our code around
dealing with status-log, and reduce load on controllers looking after
hundreds or thousands of units.

Is anyone opposed to this change?

Tim

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

Re: Normalizing output dir for charm build

[Merlijn Sebrechts]

>
> It seems like deps should go under ~/.cache/charm-build/


+1

Now, to be clear, the structure you propose is something like the following?


├── charms# $JUJU_REPOSITORY
│   ├── my-charm
│   ├── ...
├── interfaces# $INTERFACE_PATH
│   ├── ...
├── layers# $LAYER_PATH
│   ├── ...



2017-05-10 23:39 GMT+02:00 Cory Johns <cory.jo...@canonical.com>:

> There are separate env vars for layers and interfaces, and there should
> probably be CLI args as well.  Perhaps instead of being required like the
> output dir, if they're not provided they just aren't used.
>
> It seems like deps should go under ~/.cache/charm-build/
>
> On Wed, May 10, 2017 at 3:36 PM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> * Drop the "builds" portion of the output directory (that was mainly to
>>> distinguish it from the series portion).
>>>
>>
>> We still need to distinguish the charms from `deps` and possibly from
>> `layers` and `interfaces`.
>>
>> This is my $JUJU_REPOSITORY:
>>
>> ├── charms
>> │   ├── builds
>> │   ├── deps
>> │   ├── interfaces
>> │   ├── layers
>>
>>
>> 2017-05-10 20:03 GMT+02:00 Cory Johns <cory.jo...@canonical.com>:
>>
>>> Started on https://github.com/juju/charm-tools/pull/320, I'd like to
>>> bring this discussion to the list.
>>>
>>> The output directory for charm build can vary in seemingly unpredictable
>>> ways depending on how it is called, the environment, and the charm's
>>> metadata.yaml contents.  This is due to historical reasons, primarily with
>>> how Juju 1.x worked and how charm paths worked prior to the advent of
>>> multi-series charms.  However, now that 2.x and multi-series support are
>>> standard, I would like to push for simplifying the output directory, based
>>> on Merlijn's PR.
>>>
>>> Specifically, I'd like to push for the following changes:
>>>
>>> * Drop the series portion of the output directory (we recommend
>>> providing the series in the charm's metadata, making it redundant in the
>>> path).
>>> * Drop the "builds" portion of the output directory (that was mainly to
>>> distinguish it from the series portion).
>>> * Drop the current directory as a fallback option for the output
>>> directory (it causes more confusion than it saves).
>>>
>>> Thus, charm build would always require an output directory to be given
>>> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
>>> variable, and would always put the built charm in $output_dir/$charm_name
>>>
>>> Obviously, this is not backwards compatible, and may affect automated
>>> build systems, but I think it would be easy to adjust for and simplify
>>> things for everyone concerned.
>>>
>>> Thoughts?  Objections?
>>>
>>> --
>>> 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: Normalizing output dir for charm build

[Merlijn Sebrechts]

>
> * Drop the "builds" portion of the output directory (that was mainly to
> distinguish it from the series portion).
>

We still need to distinguish the charms from `deps` and possibly from
`layers` and `interfaces`.

This is my $JUJU_REPOSITORY:

├── charms
│   ├── builds
│   ├── deps
│   ├── interfaces
│   ├── layers


2017-05-10 20:03 GMT+02:00 Cory Johns :

> Started on https://github.com/juju/charm-tools/pull/320, I'd like to
> bring this discussion to the list.
>
> The output directory for charm build can vary in seemingly unpredictable
> ways depending on how it is called, the environment, and the charm's
> metadata.yaml contents.  This is due to historical reasons, primarily with
> how Juju 1.x worked and how charm paths worked prior to the advent of
> multi-series charms.  However, now that 2.x and multi-series support are
> standard, I would like to push for simplifying the output directory, based
> on Merlijn's PR.
>
> Specifically, I'd like to push for the following changes:
>
> * Drop the series portion of the output directory (we recommend providing
> the series in the charm's metadata, making it redundant in the path).
> * Drop the "builds" portion of the output directory (that was mainly to
> distinguish it from the series portion).
> * Drop the current directory as a fallback option for the output directory
> (it causes more confusion than it saves).
>
> Thus, charm build would always require an output directory to be given
> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
> variable, and would always put the built charm in $output_dir/$charm_name
>
> Obviously, this is not backwards compatible, and may affect automated
> build systems, but I think it would be easy to adjust for and simplify
> things for everyone concerned.
>
> Thoughts?  Objections?
>
> --
> 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 remove credential from JaaS?

[Merlijn Sebrechts]

Works like a Charm, thanks!

2017-05-06 22:49 GMT+02:00 Rick Harding <rick.hard...@canonical.com>:

> Sure thing Merlijn. There's a WIP account page that you can get to via
> https://jujucharms.com/account/
>
> That has a list of your creds and allows you to remove them.
>
> I know there was some work to link that account page to the normal header
> UX. I'll check with the progress of that next week.
>
> Let me know how that works out.
>
> Rick
>
> On Sat, May 6, 2017 at 3:20 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> Is it possible to remove a credential from JaaS?
>>
>>
>>
>> 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

How to remove credential from JaaS?

[Merlijn Sebrechts]

Hi all


Is it possible to remove a credential from JaaS?



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

Re: [ANN] Bigtop-1.2 charms/bundles have been released

[Merlijn Sebrechts]

Awesome!

Some visibility improvements.

   - If you search for Hadoop  in the
   Charm Store, the first results you get are the old non-bigtop charms. Can
   we do something about this? This is the same for Spark, Pig, etc..
   - The ancient "hadoop"  Charms
   are still in the store and stil "recommended".
   - If you search for "bigtop", you only see one bundle while there are a
   bunch of bigtop bundles: https://jujucharms.com/q/bigtop?type=bundle
   - If you click on the search bar in the store without typing
   something[1] we see a bunch of old bigdata charms. This should show the
   latest and gratest.
   - The bigtop Spark charm doesn't seem to have bigtop in its icon?
   https://jujucharms.com/spark/ 
   - There are still a bunch of charms that don't list what version they
   install in the description.


[1]
[image: Inline afbeelding 1]

2017-04-25 18:54 GMT+02:00 Kevin Monroe :

> Hi folks!
>
> After over a year in development, Apache Bigtop 1.2 was released earlier
> this month.  Today, we released updated charms and bundles for this release
> to the appropriate stable channels.
>
> HIGHLIGHTS:
>
> + Software versions:
> - hadoop-namenode 2.7.3
> - hadoop-plugin 2.7.3
> - hadoop-resourcemanager 2.7.3
> - hadoop-slave 2.7.3
> - hbase 1.1.3-1 **
> - kafka 0.10.1.1-1
> - mahout 0.12.2-1 **
> - pig 0.15.0
> - spark 2.1.0-1
> - zeppelin 0.7.0
> - zookeeper 3.4.6-1 **
>
> ** There is a planned bigtop-1.2.1 point release to bring in hotfixes.
> This will likely include hbase-1.1.9, mahout-0.13, and zookeeper-3.4.10.
> No charm changes are required; when these debs hit the upstream repo, the
> charms will provide the new version.
>
> + Juju 2.0 or greater
> - To leverage Juju Resources, bigtop-related charms now require Juju 2 or
> greater.
>
> + Usability
> - Refreshed READMEs and actions for a consistent UX
>
> + Hadoop-Spark
> - Reduced resource requirements.  Spark is not in HA mode in this bundle,
> so we removed 3 unnecessary zookeeper units.
>
> + Spark
> - New configuration to change driver/executor memory at runtime.
> - Improved spark reliability when changing execution mode (local,
> standalone, yarn).
>
>
> KNOWN ISSUES:
>
> + GCE
> - https://bugs.launchpad.net/juju/+bug/1674871
> - Most of our applications require a minimum of 7g ram.  We set a generic
> memory constraint in our bundles for a consistent experience across all
> clouds.  However, with GCE, mem=7G results in a "highcpu" instance type.
> These are significantly more expensive than "standard" instance types.
> - If "highcpu" instances are not required, workaround this issue by
> modifying a local copy of bundle.yaml.  For example:
>
> $ charm pull hadoop-processing
> cs:bundle/hadoop-processing-58
> $ cd hadoop-processing/
> $ sed -ie 's/mem=7G/instance-type=n1-standard-2/' bundle.yaml
> $ juju deploy ./bundle.yaml
>
> + Zeppelin
> - https://issues.apache.org/jira/browse/BIGTOP-2742
> - The init script for the zeppelin service is broken.  The charm will work
> around this during install and relation changes, but users may find that
> things like "sudo systemctl  zeppelin" on the unit do not work.
> - We'll update the zeppelin charm once an appropriate fix lands upstream.
>
>
> Please let me know if you have any questions or issues with the bigtop-1.2
> release.  Thanks!
> -Kevin Monroe
>
> --
> 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

A+ HTTPS with the SSL termination proxy

[Merlijn Sebrechts]

Hi all


Want to have A+ HTTPS for your juju-managed webservice? Want to secure a
webservice with a password? The SSL termination proxy charm
 to your rescue!

It's a reverse proxy that encrypts traffic using a Let's Encrypt
certificate with optional Basic Authentication. Deploy the charm, set fqdn,
connect to your webservice, and go! The deployed proxy gets an A+ ssl
rating on the Qualis SSL Server Test.

It's not ready yet to be promulgated but it should work fine for demo
deployment so give it a test drive if you're interested.

If anyone wants to work together on this charm to expand its scope, let me
know! I'm thinking about stuff like pluggable authentication backends,
pluggable DNS backends, support for more protocols such as websockets, ...



*PS: The charm currently doesn't work on JaaS due to a bug with charms with
terms , but that should
change soon as the bug has high priority.*


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

Re: Thank you!

[Merlijn Sebrechts]

What about speed an velocity? Does a more focused Canonical mean more
resources for Juju?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Thank you!

[Merlijn Sebrechts]

A very big +1

Any official word on what this will mean for Juju?

2017-04-20 12:43 GMT+02:00 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Check out the openvpn charm form the tengu team

[Merlijn Sebrechts]

2017-04-14 16:10 GMT+02:00 Marco Ceppi <marco.ce...@canonical.com>:

> I'd like to point you both to this idea, which is one that was born from
> the same problem Kubernetes has: https://bugs.launchpad.ne
> t/juju/+bug/1670838. The idea is actions should be able to both send and
> receive files.
>

+1

One thing to consider here is that actions always have to be triggered from
the operator side. It would also be nice if the charm cloud periodically
push a backup to the controller without the operator having to call an
action.




> As actions are exposed in the GUI this could help address the above
> problem as well.
>


>From what I know, actions aren't yet supported in the GUI:
https://github.com/juju/juju-gui/issues/2185



>
> On Fri, Apr 14, 2017 at 10:07 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Yes, "inverse resources" is what I'm thinking about. Another use-case for
>> this would be to download backups and exports from the Charm. The
>> Kubernetes Charms could also benefit from this since they create a config
>> file that an operator has to download to connect to the Kubernetes cluster.
>>
>> `juju scp` solves this issue for the most part but
>>
>>1. it isn't available from the GUI
>>2. and the files disappear when the node goes down.
>>
>>
>> 2017-04-14 15:55 GMT+02:00 Rick Harding <rick.hard...@canonical.com>:
>>
>>> The delivery of the config files is interesting. There's nothing
>>> planning in the gui at the moment for this. It's kind of an inverse
>>> "resources" idea where you are building artifacts in the charm that you
>>> want clients to be able to get access to. It's an interesting concept. It's
>>> a bit like actions that generate a backup file or the like. The action can
>>> build the backup and tell you where on disk it is, but then you need to
>>> juju scp it down. I wonder if there's a specific action type that generates
>>> artifacts and then there's a followup plugin/helper that automates the juju
>>> scp step for you in a some nice way.
>>>
>>> I think that Chuck was looking to have a relation available. In this way
>>> you could tunnel traffic from an application across the VPN perhaps? In the
>>> world of cross model relations it might enable folks to wire traffic across
>>> clouds/DC in some interesting ways.
>>>
>>>
>>>
>>> On Fri, Apr 14, 2017 at 9:47 AM Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
>>>> Thanks for the post!
>>>>
>>>>
>>>> I'd really like to integrate this Charm more with JaaS. I'd like to
>>>> give JaaS users the ability to download the client config files from the
>>>> Juju GUI. Any idea if that's something that's being worked on?
>>>>
>>>> @chuck: I just watched the Juju show, what was the feature you were
>>>> talking about?
>>>>
>>>>
>>>>
>>>> Kind regards
>>>> Merlijn
>>>>
>>>> 2017-04-13 16:35 GMT+02:00 Rick Harding <rick.hard...@canonical.com>:
>>>>
>>>>> I wrote up a quick blog post [1] as I was tinkering with VPNs and the
>>>>> OpenVPN charm [2] from the Tengu team is really nice and easy. It also 
>>>>> does
>>>>> some great work using metrics in Juju to output operational data. Running
>>>>> juju metrics --all will show you how many clients are connected on each
>>>>> unit. If you're a charmer, it might give you some new ideas for exposing
>>>>> internal data in a really nice standard way.
>>>>>
>>>>> I just wanted to highlight it as something really useful for folks if
>>>>> you've ever found yourself wishing you had a VPN around somewhere.
>>>>>
>>>>> 1: http://mitechie.com/blog/2017/4/12/three-reasons-you-need
>>>>> -to-keep-a-vpn-in-your-pocket
>>>>> 2: https://jujucharms.com/openvpn/
>>>>>
>>>>> Rick
>>>>>
>>>>> --
>>>>> 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

Re: Check out the openvpn charm form the tengu team

[Merlijn Sebrechts]

Yes, "inverse resources" is what I'm thinking about. Another use-case for
this would be to download backups and exports from the Charm. The
Kubernetes Charms could also benefit from this since they create a config
file that an operator has to download to connect to the Kubernetes cluster.

`juju scp` solves this issue for the most part but

   1. it isn't available from the GUI
   2. and the files disappear when the node goes down.


2017-04-14 15:55 GMT+02:00 Rick Harding <rick.hard...@canonical.com>:

> The delivery of the config files is interesting. There's nothing planning
> in the gui at the moment for this. It's kind of an inverse "resources" idea
> where you are building artifacts in the charm that you want clients to be
> able to get access to. It's an interesting concept. It's a bit like actions
> that generate a backup file or the like. The action can build the backup
> and tell you where on disk it is, but then you need to juju scp it down. I
> wonder if there's a specific action type that generates artifacts and then
> there's a followup plugin/helper that automates the juju scp step for you
> in a some nice way.
>
> I think that Chuck was looking to have a relation available. In this way
> you could tunnel traffic from an application across the VPN perhaps? In the
> world of cross model relations it might enable folks to wire traffic across
> clouds/DC in some interesting ways.
>
>
>
> On Fri, Apr 14, 2017 at 9:47 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Thanks for the post!
>>
>>
>> I'd really like to integrate this Charm more with JaaS. I'd like to give
>> JaaS users the ability to download the client config files from the Juju
>> GUI. Any idea if that's something that's being worked on?
>>
>> @chuck: I just watched the Juju show, what was the feature you were
>> talking about?
>>
>>
>>
>> Kind regards
>> Merlijn
>>
>> 2017-04-13 16:35 GMT+02:00 Rick Harding <rick.hard...@canonical.com>:
>>
>>> I wrote up a quick blog post [1] as I was tinkering with VPNs and the
>>> OpenVPN charm [2] from the Tengu team is really nice and easy. It also does
>>> some great work using metrics in Juju to output operational data. Running
>>> juju metrics --all will show you how many clients are connected on each
>>> unit. If you're a charmer, it might give you some new ideas for exposing
>>> internal data in a really nice standard way.
>>>
>>> I just wanted to highlight it as something really useful for folks if
>>> you've ever found yourself wishing you had a VPN around somewhere.
>>>
>>> 1: http://mitechie.com/blog/2017/4/12/three-reasons-you-
>>> need-to-keep-a-vpn-in-your-pocket
>>> 2: https://jujucharms.com/openvpn/
>>>
>>> Rick
>>>
>>> --
>>> 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: Check out the openvpn charm form the tengu team

[Merlijn Sebrechts]

Thanks for the post!


I'd really like to integrate this Charm more with JaaS. I'd like to give
JaaS users the ability to download the client config files from the Juju
GUI. Any idea if that's something that's being worked on?

@chuck: I just watched the Juju show, what was the feature you were talking
about?



Kind regards
Merlijn

2017-04-13 16:35 GMT+02:00 Rick Harding :

> I wrote up a quick blog post [1] as I was tinkering with VPNs and the
> OpenVPN charm [2] from the Tengu team is really nice and easy. It also does
> some great work using metrics in Juju to output operational data. Running
> juju metrics --all will show you how many clients are connected on each
> unit. If you're a charmer, it might give you some new ideas for exposing
> internal data in a really nice standard way.
>
> I just wanted to highlight it as something really useful for folks if
> you've ever found yourself wishing you had a VPN around somewhere.
>
> 1: http://mitechie.com/blog/2017/4/12/three-reasons-you-
> need-to-keep-a-vpn-in-your-pocket
> 2: https://jujucharms.com/openvpn/
>
> Rick
>
> --
> 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: Goodbye Opsworks

[Merlijn Sebrechts]

Any ideas to write a blogpost about it? I'm curious about what problems
Juju solves that were hard with opswork and your experience in making the
switch.

2017-04-01 3:06 GMT+02:00 James Beedy :

> The day has finally come for me to turn down the last of our Opsworks
> instances for our PRM application. This marks the completion of one of many
> Opsworks -> Juju conversion projects I've taken on. Thanks everyone for
> your help along the way!
>
> Goodbye Opsworks - http://imgur.com/a/4pkgP
>
> Hello Juju PRM!
>
> Staging - http://paste.ubuntu.com/24291143/
> Demo - http://paste.ubuntu.com/24291156/
> Production - http://paste.ubuntu.com/24291133/
> Walmart - http://paste.ubuntu.com/24291173/
>
> W00T!
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: [Review Queue] Elastisys Charmscaler Promulgated!

[Merlijn Sebrechts]

PS: The in-page links in your README don't work in the charm store because
of this bug: https://github.com/juju/juju-gui/issues/2650
If you want' add a :+1: to that bug so they know I'm not the only one using
such links ;)

PPS: I saw *"By using the Elastisys CharmScaler, you agree to its license
and privacy statement."* at the bottom of your readme. You might want to
look at the "terms" feature. https://jujucharms.com/docs/2.1/developer-terms

2017-03-21 14:10 GMT+01:00 Merlijn Sebrechts <merlijn.sebrec...@gmail.com>:

> The issue I see here is that there is much more momentum behind stuff like
> Nagios. It would be great if you could just plug this into existing
> monitoring/metrics solutions.
>
> I see the Charm has some Nagios-related config options and relations, is
> there some documentation about how this charm integrates with Nagios?
>
> 2017-03-21 13:36 GMT+01:00 Simon Kollberg <simon.kollb...@elastisys.com>:
>
>>
>>
>> On 21 March 2017 at 13:00, Merlijn Sebrechts <merlijn.sebrec...@gmail.com
>> > wrote:
>>
>>> Awesome stuff!
>>>
>>> Would it make sense to expose the autoscaling options over an
>>> interface/relationship? So that you can connect the autoscaler to a charm
>>> and the charm tells the autoscaler how it should be scaled
>>>
>>
>> Yea! It would be really good to let developers decide which metrics is
>> the most useful to look at when autoscaling their application, especially
>> since that is one of the big strengths in Juju - letting the experts give
>> you sane defaults.
>>
>> I've been juggling the idea about integrating the Juju metrics into the
>> CharmScaler seeing how that would give the charmers an already existing
>> interface to specify their application metrics. However, as it stands right
>> now, Juju only collects those metrices every five minutes which obviously
>> wouldn't be a sufficient rate for smooth autoscaling.
>>
>>
>>>
>>>
>>> 2017-03-20 21:54 GMT+01:00 Simon Kollberg <simon.kollb...@elastisys.com>
>>> :
>>>
>>>>
>>>>
>>>> On 20 March 2017 at 18:13, Charles Butler <charles.but...@canonical.com
>>>> > wrote:
>>>>
>>>>> Greetings,
>>>>>
>>>>> I realized last week I had completed a review and failed to send an
>>>>> update to the mailing list. As some of you may have heard on the Juju Show
>>>>> that Elastisys released their Charm Scaler to the promulgated channel.
>>>>>
>>>>>
>>>>> This was an easy +1 from me, with comprehensive test suites, and
>>>>> example cases for auto-horizontal-scaling workloads based on CPU load.
>>>>>
>>>>> https://jujucharms.com/charmscaler/
>>>>>
>>>>>
>>>> Thanks a lot for the review, Charles!
>>>>
>>>> We're really looking forward to see the community use our autoscaler to
>>>> increase performance and availability for all of the awesome charms out
>>>> there and we hope the CharmScaler can become a great addition to the Juju
>>>> ecosystem. The CharmScaler is very much in it's infancy when it comes to
>>>> functionality but we are planning on extending it with a lot of features
>>>> that is already available in the Elastisys platform such as support for
>>>> more built-in and custom metrics, smarter scaling-algorithms and
>>>> robustness. We also welcome PRs, feature requests and/or bug reports on the
>>>> charm's GitHub page https://github.com/elastisys/layer-charmscaler .
>>>>
>>>>
>>>>> This particular charm is near and dear to my own interests, as they
>>>>> have published a POC bundle using Canonical Distribution of Kubernetes as
>>>>> the subject matter. Enjoy horizontally scaled workers when you reach node
>>>>> pressure thresholds on CPU.
>>>>>
>>>>> https://jujucharms.com/u/elastisys/autoscaled-kubernetes/0
>>>>>
>>>>
>>>> Seeing how easy Juju makes bundling charms together building and
>>>> deploying the autoscaled Kubernetes was a sheer pleasure. To be honest,
>>>> what took me the most time was creating a (sort of) nice look for the GUI.
>>>> :) However, I think we should go one step further. Rather than having to
>>>> create a completely new bundle every time you want to extend a "core"
>>>> bundle with one or more charms, why not 

Re: [Review Queue] Elastisys Charmscaler Promulgated!

[Merlijn Sebrechts]

The issue I see here is that there is much more momentum behind stuff like
Nagios. It would be great if you could just plug this into existing
monitoring/metrics solutions.

I see the Charm has some Nagios-related config options and relations, is
there some documentation about how this charm integrates with Nagios?

2017-03-21 13:36 GMT+01:00 Simon Kollberg <simon.kollb...@elastisys.com>:

>
>
> On 21 March 2017 at 13:00, Merlijn Sebrechts <merlijn.sebrec...@gmail.com>
> wrote:
>
>> Awesome stuff!
>>
>> Would it make sense to expose the autoscaling options over an
>> interface/relationship? So that you can connect the autoscaler to a charm
>> and the charm tells the autoscaler how it should be scaled
>>
>
> Yea! It would be really good to let developers decide which metrics is the
> most useful to look at when autoscaling their application, especially since
> that is one of the big strengths in Juju - letting the experts give you
> sane defaults.
>
> I've been juggling the idea about integrating the Juju metrics into the
> CharmScaler seeing how that would give the charmers an already existing
> interface to specify their application metrics. However, as it stands right
> now, Juju only collects those metrices every five minutes which obviously
> wouldn't be a sufficient rate for smooth autoscaling.
>
>
>>
>>
>> 2017-03-20 21:54 GMT+01:00 Simon Kollberg <simon.kollb...@elastisys.com>:
>>
>>>
>>>
>>> On 20 March 2017 at 18:13, Charles Butler <charles.but...@canonical.com>
>>> wrote:
>>>
>>>> Greetings,
>>>>
>>>> I realized last week I had completed a review and failed to send an
>>>> update to the mailing list. As some of you may have heard on the Juju Show
>>>> that Elastisys released their Charm Scaler to the promulgated channel.
>>>>
>>>>
>>>> This was an easy +1 from me, with comprehensive test suites, and
>>>> example cases for auto-horizontal-scaling workloads based on CPU load.
>>>>
>>>> https://jujucharms.com/charmscaler/
>>>>
>>>>
>>> Thanks a lot for the review, Charles!
>>>
>>> We're really looking forward to see the community use our autoscaler to
>>> increase performance and availability for all of the awesome charms out
>>> there and we hope the CharmScaler can become a great addition to the Juju
>>> ecosystem. The CharmScaler is very much in it's infancy when it comes to
>>> functionality but we are planning on extending it with a lot of features
>>> that is already available in the Elastisys platform such as support for
>>> more built-in and custom metrics, smarter scaling-algorithms and
>>> robustness. We also welcome PRs, feature requests and/or bug reports on the
>>> charm's GitHub page https://github.com/elastisys/layer-charmscaler .
>>>
>>>
>>>> This particular charm is near and dear to my own interests, as they
>>>> have published a POC bundle using Canonical Distribution of Kubernetes as
>>>> the subject matter. Enjoy horizontally scaled workers when you reach node
>>>> pressure thresholds on CPU.
>>>>
>>>> https://jujucharms.com/u/elastisys/autoscaled-kubernetes/0
>>>>
>>>
>>> Seeing how easy Juju makes bundling charms together building and
>>> deploying the autoscaled Kubernetes was a sheer pleasure. To be honest,
>>> what took me the most time was creating a (sort of) nice look for the GUI.
>>> :) However, I think we should go one step further. Rather than having to
>>> create a completely new bundle every time you want to extend a "core"
>>> bundle with one or more charms, why not enable bundles in the bundle
>>> manifests? That way two or more bundles could be combined just like charms.
>>> I know I'm not the first one to bring this up, so if this has already been
>>> requested on the mailing-list excuse this and just count it as a +1!
>>>
>>>
>>>>
>>>>
>>>> Congratulations on your promulgation status to our friends
>>>> at Elastisys!  I look forward to seeing the bundles this charm unlocks the
>>>> auto-scaling goodness thanks to tight integration with Juju.
>>>>
>>>
>>> We are very excited to see our charm getting the Juju stamp of approval!
>>> Thanks again.
>>>
>>>
>>>>
>>>> All the best,
>>>>
>>>> Charles
>>>> --
>>>> 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/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

Re: [Review Queue] Elastisys Charmscaler Promulgated!

[Merlijn Sebrechts]

Awesome stuff!

Would it make sense to expose the autoscaling options over an
interface/relationship? So that you can connect the autoscaler to a charm
and the charm tells the autoscaler how it should be scaled


2017-03-20 21:54 GMT+01:00 Simon Kollberg :

>
>
> On 20 March 2017 at 18:13, Charles Butler 
> wrote:
>
>> Greetings,
>>
>> I realized last week I had completed a review and failed to send an
>> update to the mailing list. As some of you may have heard on the Juju Show
>> that Elastisys released their Charm Scaler to the promulgated channel.
>>
>>
>> This was an easy +1 from me, with comprehensive test suites, and example
>> cases for auto-horizontal-scaling workloads based on CPU load.
>>
>> https://jujucharms.com/charmscaler/
>>
>>
> Thanks a lot for the review, Charles!
>
> We're really looking forward to see the community use our autoscaler to
> increase performance and availability for all of the awesome charms out
> there and we hope the CharmScaler can become a great addition to the Juju
> ecosystem. The CharmScaler is very much in it's infancy when it comes to
> functionality but we are planning on extending it with a lot of features
> that is already available in the Elastisys platform such as support for
> more built-in and custom metrics, smarter scaling-algorithms and
> robustness. We also welcome PRs, feature requests and/or bug reports on the
> charm's GitHub page https://github.com/elastisys/layer-charmscaler .
>
>
>> This particular charm is near and dear to my own interests, as they have
>> published a POC bundle using Canonical Distribution of Kubernetes as the
>> subject matter. Enjoy horizontally scaled workers when you reach node
>> pressure thresholds on CPU.
>>
>> https://jujucharms.com/u/elastisys/autoscaled-kubernetes/0
>>
>
> Seeing how easy Juju makes bundling charms together building and deploying
> the autoscaled Kubernetes was a sheer pleasure. To be honest, what took me
> the most time was creating a (sort of) nice look for the GUI. :) However, I
> think we should go one step further. Rather than having to create a
> completely new bundle every time you want to extend a "core" bundle with
> one or more charms, why not enable bundles in the bundle manifests? That
> way two or more bundles could be combined just like charms. I know I'm not
> the first one to bring this up, so if this has already been requested on
> the mailing-list excuse this and just count it as a +1!
>
>
>>
>>
>> Congratulations on your promulgation status to our friends at Elastisys!
>> I look forward to seeing the bundles this charm unlocks the auto-scaling
>> goodness thanks to tight integration with Juju.
>>
>
> We are very excited to see our charm getting the Juju stamp of approval!
> Thanks again.
>
>
>>
>> All the best,
>>
>> Charles
>> --
>> 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/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

Fwd: Make JaaS better for data scientists

[Merlijn Sebrechts]

Hi all


Juju as a Service is incredibly cool. This is a great step towards making
Juju useful for data scientists. However, there are still a number of
issues that block this adoption. This email sheds some light into how, in
our experience, a data scientist should use Juju and identifies what issues
prevent data scientists from using Juju this way.


The ideal workflow of a data scientist

1. Search the Charm store for the framework you want to use.
2. Find the right bundle such as the Apache Spark Zeppelin bundle
 and click on "add to
new model"
3. login into JaaS, click deploy and add cloud credentials.
4. Wait until the bundle is deployed completely
5. Use the GUI to go to the Zeppelin UI
6. Do data science magic.

Blockers in this workflow


   - A bunch of Charms fail when deployed from the GUI. *Juju GUI handling
   of empty config breaks promulgated charms. [1]
    [2]
    [3]
   *
   - It's not possible use the GUI to go to the Zeppelin UI because
   Zeppelin is a subordinate. *Subordinate unit details show principal unit
   details *
   - A bunch of Big Data Charms cannot be deployed from the Charm Store
   because it's not possible to upload large resources. [1]
    [2]
   
   - It's not possible to create some models with the GUI because the GUI
   doesn't understand regular relationships to a subordinate charm
   

Non-blocking issues:

   - The data scientist has no idea what version of the platform he is
   running since workload version isn't show in the GUI
   .

Enhancements:


   - Bring a GUI's application address more to the front. A user now has to
   dig into the units to see this info. This info should be front and center
   since it's the obvious next step after the model is deployed.
   - Bring advanced Charm states more to the front. Currently, a user has
   to dig into the units in the sidebar to find a very badly wrapped version
   of the unit message.
   - Putting the public IP first in the list of IP's.
   https://github.com/juju/juju-gui/issues/2598
   
   - In general, show much more info in the GUI, such as machine IP's etc.

Next steps

If the data scientists likes what he sees, he'll have a few questions.

1. How do I get ssh access to the machines themselves?
2. How do I connect my own applications to this model?

>From our experience, many data scientists want a web UI to do that stuff.
Installing an Ubuntu system + Juju and all its tools and configuring the
tools to connect to the model is a lot of work. This is where Data
Scientists drop out, they don't want to invest so much time just to connect
to their cluster. This is the exact reason why I built the Eclipse Che Charm
. An in-browser IDE + Console +
Charmbox.

Blockers for next steps


   - The GUI borks on the Eclipse Che Charm because it tries to parse the
   >30.000 open ports that Eclipse Che has.
    The CLI shows this
   correctly as a port range but the GUI doesn't. So we need the CLI to find
   the url to go to eclipse che but we need access to eclipse che to get a
   cli. Chicken or egg?

Non-blocking issues:



   - There is no way to export model info from the GUI and import it into
   the CLI.  Another approach
   to this might be to piggyback on the idea of exposing the controller as an
   application in the "controller" model. The eclipse-che charm can then
   connect to the controller charm to import that information.



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

Cannot update bugs-url of promulgated charm

[Merlijn Sebrechts]

When I want to update the bugs-url of a promulgated charm I get an
unauthorized error. Is this a bug or am I doing something wrong?

charm set cs:~tengu-team/eclipse-che bugs-url=
https://github.com/tengu-team/layer-eclipse-che/issues
ERROR cannot update the set arguments provided: unauthorized: access denied
for user "merlijn-sebrechts"
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Snap Changes

[Merlijn Sebrechts]

Thanks for the thorough explanation!

2017-03-01 7:07 GMT+01:00 John Meinel :

> ...
>>
>
>
>> I'm having a hard time wrapping my head around classic mode. Classic mode
>> means unconfined, right?
>>
>> What are the reasons for this switch? Is the snap still cross-distro?
>> Will the snap have some expectations about the system outside of the snap?
>> What are the advantages of an unconfined snap over a deb package?
>>
>
> To get a deb package, you have to generally add something like a PPA,
> which means you now get anything they want to give you from that PPA. Core
> libraries, a new kernel, whatever. Once you've accepted the terms of a PPA,
> you're trusting that person not to hose you over.
>
> While classic snaps still have access to the rest of the filesystem, they
> 1) Still include their dependencies inside their containment, rather than
> producing other packages that you must also install.
> 2) Can't muck with things outside of that (so saying 'snap install juju
> --classic' won't be able to change package kernel)
> 3) Give you all the nice release cadence, etc of other snaps. Mainly
> things like "I'm willing to run beta", "I only want to run candidate+" etc.
> 4) Are definitely no-less secure than deb packages.
> 5) Can get your software into snaps immediately, and you can transition
> into more confinement as you can make it work.
> 6) Snaps apply transactionally. An update can't partially apply half of
> the update and then fail (if it does, the whole update is rolled back).
>
>
>>
>> This isn't strictly Juju related, but maybe you can shed some light on
>> this. I don't follow the project close enough to understand this feature.
>> Confinement was key to the goals of snaps, ever since the click days.. Why
>> the 180 now?
>>
>
> Confinement is great for a lot of things, but not everything. Vim confined
> to not be able to read your .bashrc file isn't a very good vim. Juju
> doesn't need access to everything, so there is still room to grow support
> in Snap confinement to limit you to the right subset (we do want to read
> .ssh/id_rsa* and .local/share/juju, we don't need to read
> .mozilla/firefox/...)
>
>
>>
>> I would think that if an application like Juju can't work in a confined
>> snap, then snaps have an inherent flaw that needs to be fixed instead of
>> having the workaround of the classic mode. Paraphrasing the story I've
>> heard so many times: Snaps enable devs to push code directly to users
>> without having to go through the long review process of the distro.
>> Security and stability concerns are countered with confinement. Snaps
>> enable devs to package once, run anywhere. Confinement + frameworks makes
>> this possible...
>>
>> Snaps without confinement just seems like someone just brought .debs into
>> the 21 century, and that seems very underwhelming to me. What am I missing
>> here?
>>
>>
> The distribution model and the dependency model are a lot nicer.
> Transactional updates to the packages is also *extremely* nice.
>
> John
> =:->
>
>
>>
>> Kind regards
>> Merlijn
>>
>> 2017-02-28 20:52 GMT+01:00 Nicholas Skaggs > >:
>>
>>> Those of you subscribed to a snap channel may have noticed some nice
>>> changes that happened with 2.1 release. The juju snap package now utilizes
>>> classic mode, and all channels (including stable) are now active. You
>>> should expect feature parity (including things like bash completion) with
>>> the debian package of juju. In addition, the juju snap also shares
>>> environments with the debian installed version. This means your current
>>> models and credentials are utilized.
>>>
>>> I would encourage those that haven't yet tried out the snap to do so and
>>> provide feedback. I think you'll find it a quick and easy way to get juju.
>>>
>>> snap install juju --classic
>>>
>>> Those of you who want to build your own snap 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

Re: Juju Snap Changes

[Merlijn Sebrechts]

Hi Nicholas


I'm having a hard time wrapping my head around classic mode. Classic mode
means unconfined, right?

What are the reasons for this switch? Is the snap still cross-distro? Will
the snap have some expectations about the system outside of the snap? What
are the advantages of an unconfined snap over a deb package?

This isn't strictly Juju related, but maybe you can shed some light on
this. I don't follow the project close enough to understand this feature.
Confinement was key to the goals of snaps, ever since the click days.. Why
the 180 now?

I would think that if an application like Juju can't work in a confined
snap, then snaps have an inherent flaw that needs to be fixed instead of
having the workaround of the classic mode. Paraphrasing the story I've
heard so many times: Snaps enable devs to push code directly to users
without having to go through the long review process of the distro.
Security and stability concerns are countered with confinement. Snaps
enable devs to package once, run anywhere. Confinement + frameworks makes
this possible...

Snaps without confinement just seems like someone just brought .debs into
the 21 century, and that seems very underwhelming to me. What am I missing
here?



Kind regards
Merlijn

2017-02-28 20:52 GMT+01:00 Nicholas Skaggs :

> Those of you subscribed to a snap channel may have noticed some nice
> changes that happened with 2.1 release. The juju snap package now utilizes
> classic mode, and all channels (including stable) are now active. You
> should expect feature parity (including things like bash completion) with
> the debian package of juju. In addition, the juju snap also shares
> environments with the debian installed version. This means your current
> models and credentials are utilized.
>
> I would encourage those that haven't yet tried out the snap to do so and
> provide feedback. I think you'll find it a quick and easy way to get juju.
>
> snap install juju --classic
>
> Those of you who want to build your own snap 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/mailman/listinfo/juju

Re: Juju GUI handling of empty config breaks promulgated charms

[Merlijn Sebrechts]

This - is - awesome !

I guess this hack will still require a rebuild for the affected Charms?

2017-02-22 16:41 GMT+01:00 Stuart Bishop <stuart.bis...@canonical.com>:

> On 21 February 2017 at 16:30, Merlijn Sebrechts
> <merlijn.sebrec...@gmail.com> wrote:
> > Thanks, Stuart!
> >
> > Now I get a different error. It seems that the charm really can't handle
> > null as a string value.
>
> Rather than comb through the charm updating all the call sites, I've
> made a hack to ensure config values never get returned as null. I also
> didn't want to change the style, as the alternative (using
> config.get()) can hide other bugs.
>
> Other charms will have the same problem, so this should certainly be
> fixed in Juju.
>
> --
> 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: Generic VNF Configuration and Management talk from Config Management Camp

[Merlijn Sebrechts]

Thanks for posting,  Adam! I wanted to see the talk, but I forgot.. Very
good presentation, answers a bunch of questions I had.

2017-02-22 11:00 GMT+01:00 Adam Israel :

> Hey everyone,
>
> As part of the recent CfgMgmtCamp in Ghent, Belgium, I gave a talk on the
> main track titled Generic VNF Configuration and Management.
>
> Much to my introverted horror ;) , it was filmed and is now available for
> everyone to see. If you have any interest in NFV, VNFs, or the
> telecommunication space, you may find it useful.
>
> https://www.youtube.com/watch?v=en6P3WawUBA=6=
> PLBZBIkixHEidnVKFIxogd3Qf-ai3RKTJ_
>
> -Adam
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
>
> --
> 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 GUI handling of empty config breaks promulgated charms

[Merlijn Sebrechts]

Awesome, thanks!

2017-02-21 14:12 GMT+01:00 Stuart Bishop <stuart.bis...@canonical.com>:

> On 21 February 2017 at 16:44, Merlijn Sebrechts
> <merlijn.sebrec...@gmail.com> wrote:
> > PS: This bug was reported a few months ago by one of my colleagues, but
> he
> > didn't get a reply: https://bugs.launchpad.net/
> cassandra-charm/+bug/1645821
> >
> > Is that the correct place to file bugs for the charm?
>
> Yes. I'm now correctly subscribed, so will see them in the future.
>
>
> --
> 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: Juju GUI handling of empty config breaks promulgated charms

[Merlijn Sebrechts]

PS: This bug was reported a few months ago by one of my colleagues, but he
didn't get a reply: https://bugs.launchpad.net/cassandra-charm/+bug/1645821

Is that the correct place to file bugs for the charm?

2017-02-21 10:30 GMT+01:00 Merlijn Sebrechts <merlijn.sebrec...@gmail.com>:

> Thanks, Stuart!
>
>
> Now I get a different error. It seems that the charm really can't handle
> null as a string value.
>
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
> "/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/install", line 20,
> in 
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
> hooks.default_hook()
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
> "/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/hooks.py", line 62,
> in default_hook
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
> sm.manage()
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
> "/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/
> charmhelpers/core/services/base.py", line 135, in manage
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
> self.reconfigure_services()
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
> "/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/
> charmhelpers/core/services/base.py", line 189, in reconfigure_services
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
> self.fire_event('data_ready', service_name)
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
> "/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/
> charmhelpers/core/services/base.py", line 236, in fire_event
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
> callback(service_name)
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
> "/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/actions.py", line
> 106, in wrapper
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install return
> func(*args, **kw)
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
> "/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/actions.py", line
> 432, in configure_cassandra_rackdc
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install rack =
> config['rack'].strip() or hookenv.service_name()
> unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
> AttributeError: 'NoneType' object has no attribute 'strip'
>
>
>
> 2017-02-21 9:15 GMT+01:00 Stuart Bishop <stuart.bis...@canonical.com>:
>
>> On 21 February 2017 at 00:40, Merlijn Sebrechts
>> <merlijn.sebrec...@gmail.com> wrote:
>> > Deploying cassandra with the GUI. Cassandra installation will fail with
>> the
>> > following error.
>> >
>> > KeyError: 'http_proxy'
>> >
>> >
>> > The Cassandra charm expects config['http_proxy'] to return an empty
>> string.
>> > This is what happens when deploying Cassandra using the CLI. However,
>> > config_get crashes because the config isn't set. running config-get in
>> the
>> > hooks context shows that the http_proxy config value just isn't set.
>> >
>> > https://github.com/juju/juju-gui/issues/2486
>>
>> I've made a new release using a newer charm-helpers. According to the
>> issue comments it should work around the problem.
>>
>> I have no idea why Juju would be changing the empty string to null,
>> specially as I'm told from Juju's pov null is an invalid value for a
>> string and why setting a config value's default to null is a lint
>> error. But that contradicts the documentation for 'config-get --all',
>> which explicitly calls out config settings with non-null defaults. So
>> maybe this changed with 2.0, but there is some old code that missed
>> being updated?
>>
>> --
>> 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: Juju GUI handling of empty config breaks promulgated charms

[Merlijn Sebrechts]

Thanks, Stuart!


Now I get a different error. It seems that the charm really can't handle
null as a string value.

unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
"/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/install", line 20, in

unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
hooks.default_hook()
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
"/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/hooks.py", line 62, in
default_hook
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install sm.manage()
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
"/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/charmhelpers/core/services/base.py",
line 135, in manage
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
self.reconfigure_services()
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
"/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/charmhelpers/core/services/base.py",
line 189, in reconfigure_services
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
self.fire_event('data_ready', service_name)
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
"/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/charmhelpers/core/services/base.py",
line 236, in fire_event
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
callback(service_name)
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
"/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/actions.py", line 106,
in wrapper
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install return
func(*args, **kw)
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install   File
"/var/lib/juju/agents/unit-cassandra-a-0/charm/hooks/actions.py", line 432,
in configure_cassandra_rackdc
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install rack =
config['rack'].strip() or hookenv.service_name()
unit-cassandra-a-0: 10:28:10 INFO unit.cassandra-a/0.install
AttributeError: 'NoneType' object has no attribute 'strip'



2017-02-21 9:15 GMT+01:00 Stuart Bishop <stuart.bis...@canonical.com>:

> On 21 February 2017 at 00:40, Merlijn Sebrechts
> <merlijn.sebrec...@gmail.com> wrote:
> > Deploying cassandra with the GUI. Cassandra installation will fail with
> the
> > following error.
> >
> > KeyError: 'http_proxy'
> >
> >
> > The Cassandra charm expects config['http_proxy'] to return an empty
> string.
> > This is what happens when deploying Cassandra using the CLI. However,
> > config_get crashes because the config isn't set. running config-get in
> the
> > hooks context shows that the http_proxy config value just isn't set.
> >
> > https://github.com/juju/juju-gui/issues/2486
>
> I've made a new release using a newer charm-helpers. According to the
> issue comments it should work around the problem.
>
> I have no idea why Juju would be changing the empty string to null,
> specially as I'm told from Juju's pov null is an invalid value for a
> string and why setting a config value's default to null is a lint
> error. But that contradicts the documentation for 'config-get --all',
> which explicitly calls out config settings with non-null defaults. So
> maybe this changed with 2.0, but there is some old code that missed
> being updated?
>
> --
> 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 GUI handling of empty config breaks promulgated charms

[Merlijn Sebrechts]

Deploying cassandra with the GUI. Cassandra installation will fail with the
following error.

KeyError: 'http_proxy'


The Cassandra charm expects config['http_proxy'] to return an empty string.
This is what happens when deploying Cassandra using the CLI. However,
config_get crashes because the config isn't set. running config-get in the
hooks context shows that the http_proxy config value just isn't set.

https://github.com/juju/juju-gui/issues/2486
-- 
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

[Merlijn Sebrechts]

An update.

Related issues

   - Community charms not showing up when recommended charms exist
   <https://github.com/juju/juju-gui/issues/2435>. That's the issue that we
   hit.


   - User/teams page not accessible from Juju GUI
   <https://github.com/juju/juju-gui/issues/2476>. That issue will be fixed
   soon. *That fix will probably solve our problem* since it gives a way
   for us to give people a link to our charms.


2017-02-17 14:20 GMT+01:00 Marco Ceppi <marco.ce...@canonical.com>:

> You're not the only one and it's something that's in the works!
>
> On Fri, Feb 17, 2017, 08:02 Merlijn Sebrechts <merlijn.sebrec...@gmail.com>
> wrote:
>
>> God, I would love to have a "how many charms use this layer" search
>> function!
>>
>> 2017-02-17 13:51 GMT+01:00 Tom Barber <t...@spicule.co.uk>:
>>
>> 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 <+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/
>> mailman/listinfo/juju
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju2 behind proxy

[Merlijn Sebrechts]

The issue with an https proxy is that this is an application level tunnel,
not a network level tunnel. This means that EVERY application needs to
change its behavior. You can't change this from the OS level. Juju
correctly sets the https proxy variables, but those are only suggestions.
It is still up to the application to respect this. A bunch of applications
and libraries don't do that.

We've used an http proxy for a while, but we switched to a NATted setup
because there were just too much issues (outside of the control of Juju),
and fixing them all slowed us down a lot.

2017-02-20 10:25 GMT+01:00 Vladimir Burlakov :

> Hi Mark,
> Some thoughts/tests on how charms works after/in deployment state in proxy
> environment, f.e in deploying Kubernetes charm we stuck, cause application
> trying to connect to public http/s servers without proxy,  and it not reads
> system settings for proxy .. so maybe there (in juju) should be an option
> to redirect all (or well known, such as http/https/ftp) connection to
> outside through juju controller using it as gateway or through proxy
> itself?!
> Or am I mistaken and this option is already there? :)
>
> Thanks,
> Vladimir
>
>
> > 10 февр. 2017 г., в 9:07, Mark Shuttleworth 
> написал(а):
> >
> > On 09/02/17 12:27, Vladimir Burlakov wrote:
> >> Hi Guys,
> >> Thank you a lot, it’s worked, you really helped me. :) as said my
> >> friend:  "community - is the power !"
> >
> > :)
> >
> > Welcome aboard, Vladimir!
> >
> > One question - are we good about passing this proxy information on to
> > the various machines that get spun up? Ubuntu, CentOS, Windows etc all
> > have ways to use proxy info, and I'm interested in whether we rigorously
> > pass this to them via cloud-init.
> >
> > Mark
>
>
> --
> 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

[Merlijn Sebrechts]

God, I would love to have a "how many charms use this layer" search
function!

2017-02-17 13:51 GMT+01:00 Tom Barber <t...@spicule.co.uk>:

> 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/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 <+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/mailman/listinfo/juju

Re: All our Charms became hidden because we promulgated some

[Merlijn Sebrechts]

Hi Rick


As I explained in my original message, the Juju UI doesn't have the user
page. Clicking on the username just searches for that user.
https://demo.jujucharms.com/?search=tengu-team

I understand completely that promulgated charms should be front and center,
but doing this by hiding other results is not a good solution. At the very
least there should be an "also include community Charms" button.



Kind regards
Merlijn

2017-02-17 13:48 GMT+01:00 Rick Harding <rick.hard...@canonical.com>:

> 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

All our Charms became hidden because we promulgated some

[Merlijn Sebrechts]

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

GCE controller and machine IP's are not static

[Merlijn Sebrechts]

Hi all


I want to bring some attention to a nasty bug on GCE. The external IP that
juju gives to instances is ephemiral. This means that the IP can be changed
after stopping and restarting the instance. This is obviously not what we
want.

There is no cost advantage to an ephemiral IP so Juju should assign static
IPs by default.

Bug on launchpad: https://bugs.launchpad.net/juju/+bug/1613823



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

Re: Create Juju Charms from your browser!

[Merlijn Sebrechts]

Answers in-line.

2017-02-06 6:36 GMT+01:00 Andrew Wilkins :
>
>
> Very cool, thanks for sharing.
>
> A few things which I think would make this even better:
>  - integration with Ubuntu SSO (or GitHub OAuth, etc.)
>

This will probably be the most difficult task. Eclipse Che doesn't have any
authentication mechanism builtin. Each user has to have their own Eclipse
Che instance. Codenvy is a commercial product based on Eclipse Che that has
authentication builtin, but it is closed-source.


>  - with above: inject macaroon/token into the charmbox container, so that
> the juju CLI would be automatically logged in (would only work with
> external identity management)
>

Yes, that would be awesome! Even without the above, we might be able to do
it by supplying a token to the Che Charm.


>  - with above: Right-click "Deploy to Juju", with detection of changes to
> deployed code and an option to update.
>
>
YES! The Che team is working on a feature called "smart commands
". This will allow us to create
stuff like a `build charm` action that appears in the right-click menu of a
layer, a `build charm` command that build the currently selected layer, a
`deploy charm` command that deploys/updates the charm.

Che's speed of development is really fast, and they seem to be going in a
direction that will allow us to create deep integration between Juju and
Che.


> ... in case anyone has spare time ;)
>
> Cheers,
> Andrew
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: I still can't upload resources to the Charm store.

[Merlijn Sebrechts]

Ok, thanks for the info!

2017-02-05 19:09 GMT+01:00 Adam Stokes <adam.sto...@canonical.com>:

> I think your issue is the one that Cory reported on about the resource
> being to big of a blob for the charm store to process. I think his resource
> was at 90M while yours is 720M. See here: https://github.com/
> CanonicalLtd/jujucharms.com/issues/332
>
> According to the bug it doesn't seem like a trivial fix so it may take
> some time but the right people are aware of it and will get it addressed.
>
> On Sun, Feb 5, 2017 at 10:58 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Update: Specified the specific revision in my push command and now it
>> fails in a different way:
>>
>>
>> $charm attach ~tengu-team/apache-nifi-1 apache-nifi=./nifi-1.1.1-bin.
>> tar.gz
>> ERROR can't upload resource: cannot post resource: cannot unmarshal error
>> response "> 2.0//EN\">\n\n502 Proxy 
>> Error\n\nProxy
>> Error\nThe proxy server received an invalid\r\nresponse from an
>> upstream server.\r\nThe proxy server could not handle the request
>> > apache-nifi\">POST/charmstore/v5/~tengu-team/
>> apache-nifi-1/resource/apache-nifi.\nReason: Error
>> reading from remote server\n\nApache/2.4.7
>> (Ubuntu) Server at api.jujucharms.com Port 443\n\n":
>> invalid character '<' looking for beginning of value
>>
>>
>>
>> 2017-02-05 15:51 GMT+01:00 Adam Stokes <adam.sto...@canonical.com>:
>>
>> https://github.com/juju/charmstore-client/issues/96
>>
>> No one from that team has provided any additional input, even though I've
>> been asking and this is obviously a huge problem for users in general.
>>
>> On Sun, Feb 5, 2017, 8:13 AM Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>> Hi all
>>
>>
>> Uploading resources to the Charm store still fails for me. It seems this
>> is still the same error that I had back in Juli:
>> https://bugs.launchpad.net/ubuntu/+source/charm/+bug/1592822.
>>
>> What I run:
>>
>> wget http://apache.belnet.be/nifi/1.1.1/nifi-1.1.1-bin.tar.gz
>> charm attach ~tengu-team/apache-nifi apache-nifi=./nifi-1.1.1-bin.tar.gz
>>
>> What I get:
>>
>> ERROR can't upload resource: cannot post resource: cannot unmarshal error
>> response "> 2.0//EN\">\n\n502 Bad 
>> Gateway\n\nBad
>> Gateway\nThe proxy server received an invalid\r\nresponse from an
>> upstream server.\r\n\n\nApache/2.4.7 (Ubuntu)
>> Server at api.jujucharms.com Port 443\n\n":
>> invalid character '<' looking for beginning of value
>>
>>
>> --
>> 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: I still can't upload resources to the Charm store.

[Merlijn Sebrechts]

Update: Specified the specific revision in my push command and now it fails
in a different way:


$charm attach ~tengu-team/apache-nifi-1 apache-nifi=./nifi-1.1.1-bin.tar.gz
ERROR can't upload resource: cannot post resource: cannot unmarshal error
response "\n\n502 Proxy
Error\n\nProxy Error\nThe proxy server
received an invalid\r\nresponse from an upstream server.\r\nThe proxy
server could not handle the request POST/charmstore/v5/~tengu-team/apache-nifi-1/resource/apache-nifi.\nReason:
Error reading from remote
server\n\nApache/2.4.7 (Ubuntu) Server at
api.jujucharms.com Port 443\n\n": invalid character
'<' looking for beginning of value



2017-02-05 15:51 GMT+01:00 Adam Stokes <adam.sto...@canonical.com>:

> https://github.com/juju/charmstore-client/issues/96
>
> No one from that team has provided any additional input, even though I've
> been asking and this is obviously a huge problem for users in general.
>
> On Sun, Feb 5, 2017, 8:13 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> Uploading resources to the Charm store still fails for me. It seems this
>> is still the same error that I had back in Juli:
>> https://bugs.launchpad.net/ubuntu/+source/charm/+bug/1592822.
>>
>> What I run:
>>
>> wget http://apache.belnet.be/nifi/1.1.1/nifi-1.1.1-bin.tar.gz
>> charm attach ~tengu-team/apache-nifi apache-nifi=./nifi-1.1.1-bin.tar.gz
>>
>> What I get:
>>
>> ERROR can't upload resource: cannot post resource: cannot unmarshal error
>> response "> 2.0//EN\">\n\n502 Bad 
>> Gateway\n\nBad
>> Gateway\nThe proxy server received an invalid\r\nresponse from an
>> upstream server.\r\n\n\nApache/2.4.7 (Ubuntu)
>> Server at api.jujucharms.com Port 443\n\n":
>> invalid character '<' looking for beginning of value
>>
>>
>> --
>> 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

I still can't upload resources to the Charm store.

[Merlijn Sebrechts]

Hi all


Uploading resources to the Charm store still fails for me. It seems this is
still the same error that I had back in Juli:
https://bugs.launchpad.net/ubuntu/+source/charm/+bug/1592822.

What I run:

wget http://apache.belnet.be/nifi/1.1.1/nifi-1.1.1-bin.tar.gz
charm attach ~tengu-team/apache-nifi apache-nifi=./nifi-1.1.1-bin.tar.gz

What I get:

ERROR can't upload resource: cannot post resource: cannot unmarshal error
response "\n\n502 Bad
Gateway\n\nBad Gateway\nThe proxy server
received an invalid\r\nresponse from an upstream server.\r\n\n\nApache/2.4.7 (Ubuntu) Server at
api.jujucharms.com Port 443\n\n": invalid character
'<' looking for beginning of value
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue]: websphere liberty, canonical-livepatch, ganglia-node, gluster, openvpn

[Merlijn Sebrechts]

Thanks Cory and team!


I didn't test my Charm on a public cloud, which meant I had a code path
that wasn't executed before. I fixed it and used my Charm Developer Program
Credentials® verify on AWS. Mentioning it because those are very useful! :)

I uploaded the next version to the Charm Store; do I need to do anything
else to get a re-review?



Regards
M

2017-02-03 16:56 GMT+01:00 Cory Johns :

> Greetings!
>
> Kevin, Konstantinos, Pete, and I worked on the queue yesterday.  Got a new
> promulgation, and some feedback.  Thanks to the charming community!
>
> Feb 2, 2017:  Cory, Kevin, Kostas, Pete
>
>-
>
>Websphere Liberty
>-
>
>   https://review.jujucharms.com/reviews/48
>   -
>
>   Deployment looks good; tests pass.
>   -
>
>   +1, promulgated:
>   -
>
>  https://jujucharms.com/websphere-liberty/
>  -
>
>Canonical-Livepatch
>-
>
>   https://review.jujucharms.com/reviews/46
>   -
>
>   Good, modulo linter errors.
>   -
>
>ganglia-node
>-
>
>   https://review.jujucharms.com/reviews/51
>   -
>
>   The test.yaml appears to be missing a python-packages declaration,
>   which means that the amulet tests are missing required python packages.
>   -
>
>gluster
>-
>
>   https://review.jujucharms.com/reviews/43
>   -
>
>   There were a couple of issues we found during review.
>   -
>
>  No tests
>  -
>
>  Readme needs updates
>  -
>
>   We will have to wait for the author’s input for this.
>   -
>
>openvpn
>-
>
>   https://review.jujucharms.com/reviews/58
>   -
>
>   Charm itself looks great, but has install hook and test timeout
>   failures
>
>
>
> --
> 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

Create Juju Charms from your browser!

[Merlijn Sebrechts]

Hi all


I've been looking at Eclipse Che for a while, it is a cloud Workspace and
IDE from the Eclipse Foundation. An IDE that runs in your browser, with
docker containers as workspaces.

It's a great way to lower the barrier for new developers. Open Che in your
browser, choose the stack you want, and start coding.

I've created a Charm that deploys Eclipse Che and creates a stack that has
everything you need to start Charming. The stack is based on the `charmbox`
Docker container.

Eclipse Che Charm: https://jujucharms.com/u/tengu-team/eclipse-che/
Eclipse Che Layer: https://github.com/IBCNServices/layer-eclipse-che

Check it out and let me know what you think of it!



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

Re: Request to join ~charmers

[Merlijn Sebrechts]

An unofficial +1 from me, great work on the community!

Op zaterdag 28 januari 2017 heeft Adam Israel 
het volgende geschreven:
> I am also a +1 for Pete joining ~charmers. He's put in consistent,
thoughtful work towards making our community better.
> On Sat, Jan 28, 2017 at 9:54 AM Marco Ceppi 
wrote:
>>
>> I am a +1, I've reviewed a lot of Pete's work and he understands the
core principals of charming and will make a fine addition.
>> On Thu, Jan 26, 2017 at 11:01 AM Pete Vander Giessen <
pete.vandergies...@canonical.com> wrote:
>>>
>>> Hi All,
>>> I've been working with the Big Data team since May 2016, and have
written or contributed to our charms (see
https://github.com/juju-solutions/bigtop), and layers (e.g.
https://github.com/juju-solutions/layer-apache-bigtop-base), as well as to
the matrix testing tool and cloud weather report. I also take a trip
through the review queue with the team once a week, and would like to be
able to finish up my positive reviews with a push to the charm store, when
appropriate.
>>> Thank you for considering me,
>>> ~ PeteVG
>>>
>>> --
>>> 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
>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Can somebody look at the interface-http pull request?

[Merlijn Sebrechts]

Thanks!

2017-01-26 11:40 GMT+01:00 Adam Israel <adam.isr...@canonical.com>:

> Hi Merlijn,
>
> Sorry about that! I've responded to and merged your pull request.
>
> I'm starting a discussion internally to see how we can better observe the
> projects we maintain, so pull requests and issues get a timely response.
>
> On Thu, Jan 26, 2017 at 11:17 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> Can anybody have a look at the interface http pull request[1]? I've
>> gotten no response for 21 days. Does this interface have a maintainer?
>> Should somebody step up?
>>
>> [1] https://github.com/juju-solutions/interface-http/pull/6
>>
>>
>>
>> Kind regards
>> Merlijn
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju
>>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

The docs around charm and bundle testing need some love

[Merlijn Sebrechts]

Hi all


The testing docs need some love. The whole Charm testing ecosystem is very
complex. The docs should focus on guiding users to a best-practice
workflow. There is just too much choice to let the user figure it out
himself.

We want charmers to write Charm and Bundle tests that are compatible with

a) `bundletester` + (LXD | a cloud)
b) the review queue

c) the cwr-ci bundle


The docs should provide two best-practice workflows; one for testing charms
and one for testing bundles. Each workflow needs a working example.

The example includes a `tests.yaml` file that is compatible with a,b and c,
and it should include commands to deploy the tests locally. The example
should hide as much advanced config as possible. It's nice that you can
specify a custom glob pattern for the test files, but this is something for
advanced uses.

Some questions that the docs should answer:

- What tools should I use? (Bundletester + Amulet. cwr-ci if you want a ci
pipeline.)
- What's the best way to deploy a Charm/Bundle using amulet?
(`deployment.add` for a Charm and `find_bundle`

for a bundle)
- Which options should I use in tests.yaml?
- Reset the environment or not? Let bundletester do cleanup, or clean it up
using Amulet?
- Deploy bundle by bundletester or by amulet?
- Where can I find Charms/Bundles that have working best-practice tests?

I think we need some discussion around what the best-practice workflows for
testing are, and then we need to standardize everything around these
workflows. An example of a choice that needs to be discussed is whether
bundle tests should first execute the individual Charm tests.

- The default behavior is to do this, so that implies "yes, bundle tests
should first execute charm tests"
- Charms and bundles are promulgated independently, and cwr-ci bundle is
also going this approach. This implies that the Charms are already tested
(either by cwr-ci or the review queue). This implies "no, it's useless to
first execute charm tests because we know they've succeeded".



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

Re: Amulet doesn't find deployed units

[Merlijn Sebrechts]

The amulet Talisman code
<https://github.com/juju/amulet/blob/34de3714902e1f5cad237340ea92e09776dbe3c6/amulet/sentry.py#L352>
only creates sentries for services (applications) that are in the
deployment schema. The Kubernetes Core bundle tests just don't work.

I looked at the Canonical Kubernetes bundle and those tests load the bundle
from the bundle file
<https://github.com/juju-solutions/bundle-canonical-kubernetes/blob/master/tests/20-basic-component-check.py#L17>,
and create a Deployment with that bundle. That approach seems to be
working. I like that approach best since the tested deployment will change
when the actual bundle changes.


2017-01-16 19:59 GMT+01:00 Merlijn Sebrechts <merlijn.sebrec...@gmail.com>:

> I'm sure the bundle is being deployed, I checked with `juju status`. When
> that error message happens, both limeds and docker are already deployed,
> even though the error happens at the first "add" line.
>
> I'll post the debug output tomorrow.
>
>
> Op maandag 16 januari 2017 heeft Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> het volgende geschreven:
> > You're right, deployment.add() isn't needed - the sentries get parsed
> out of the real-time
> > Juju status.
> > Are you sure the bundle is actually being deployed before your test is
> run? You can pass
> > -vl DEBUG for more verbose output.
> > I wonder if you need to set "bundle_deploy: true" instead of
> "bundle_deploy: True"
> > in your tests.yaml.
> > On Mon, Jan 16, 2017 at 1:14 PM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
> >>
> >> Hi Tim
> >> The tests for the kubernetes-core bundle don't do `deployment.add..`. I
> thought that bundle was a good start for my tests since the bundle is
> promulgated.. Does this mean that the tests for that bundle also won't work?
> >> I added those two lines, and now I'm having the following error. The
> url itself seems wrong the Charm I'm testing isn't promulgated. The bundle
> itself should be correct since bundletester deployed the bundle
> correctly..  You can see the bundle here: https://github.com/
> IBCNServices/bundle-limeds-core
> >> bundles/limeds-core$ bundletester
> >> bundle
> >> charm-proof
>PASS
> >> 20-basic-check.py
>ERROR
> >> 
> --
> >> ERROR: bundle::20-basic-check.py
> >> [/tmp/bundletester-gIybTn/limeds-core/tests/20-basic-check.py exit 1]
> >> E
> >> ==
> >> ERROR: setUpClass (__main__.TestBundle)
> >> --
> >> Traceback (most recent call last):
> >>   File "/usr/local/lib/python3.5/dist-packages/theblues/charmstore.py",
> line 58, in _get
> >> response.raise_for_status()
> >>   File "/usr/local/lib/python3.5/dist-packages/requests/models.py",
> line 893, in raise_for_status
> >> raise HTTPError(http_error_msg, response=self)
> >> requests.exceptions.HTTPError: 404 Client Error: Not Found for url:
> https://api.jujucharms.com/v4/xenial/docker/meta/any?
> include=bundle-machine-count=bundle-metadata&
> include=bundle-unit-count=bundles-containing&
> include=charm-actions=charm-config=charm-
> metadata=common-info=extra-info=
> revision-info=stats=supported-series&
> include=manifest=tags=promulgated=perm=id
> >> During handling of the above exception, another exception occurred:
> >> Traceback (most recent call last):
> >>   File "/tmp/bundletester-gIybTn/limeds-core/tests/20-basic-check.py",
> line 18, in setUpClass
> >> cls.deployment.add('docker')
> >>   File "/usr/local/lib/python3.5/dist-packages/amulet/deployer.py",
> line 208, in add
> >> service_name, charm, branch=branch, series=service['series'])
> >>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line
> 57, in fetch
> >> series=series)
> >>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line
> 42, in get_charm
> >> return Charm(with_series(charm_path, series))
> >>   File "/usr/local/lib/python3.5/dist-packages/charmstore/lib.py",
> line 165, in __init__
> >> super(Charm, self).__init__(id, api=api, timeout=timeout)
> >>   File "/usr/local/lib/python3.5/dist-packages/charmstore/lib.py",
> line 115, in __init__
> >> AVAILABLE_INCLUDES).get('Meta')
> >