Re: Aggregate all bundle.yaml | API endpoint

[Tim Penhey]

On 14/07/18 17:23, Ilias Tsoumas wrote:
> Hello Mark,
> 
> For the sake of clarification, let's try to explain my thoughts. I want
> to understand if I can use juju's bundles as directed (acyclic) graphs.
> Is there the information about direction? If no, do you propose to use
> the bundles as undirected graphs? Otherwise, where I can find the
> aforementioned directionality?

You can think of bundles as undirected graphs, with the applications as
nodes, and the relations as edges. For any given edge between two
applications, one application is the provider, and one is the consumer
(requires). It is possible to relate two applications multiple times
over different interfaces if the charms support them.

> As @Merlijn Sebrechts  said
> 
>  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.
> 
> In this case, I should do an api call for each relation in order to
> check if the :endpoint part is under the requires or provides tag of
> metada.yaml. 

Both the requires and provides information are available in the
metadata.yaml for any given charm.

Does this answer your questions?

Tim

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

[Ilias Tsoumas]

>
> a Juju
> interface has the idea of a provider and a consumer, which I think is
> the directionality Ilias is looking for.
>

Hello Mark,

For the sake of clarification, let's try to explain my thoughts. I want to
understand if I can use juju's bundles as directed (acyclic) graphs. Is
there the information about direction? If no, do you propose to use the
bundles as undirected graphs? Otherwise, where I can find the
aforementioned directionality?

As @Merlijn Sebrechts  said

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

In this case, I should do an api call for each relation in order to check
if the :endpoint part is under the requires or provides tag of metada.yaml.

Thank you,
Ilias

On Sat, Jul 14, 2018 at 3:57 PM Mark Shuttleworth  wrote:

> On 07/05/2018 11:22 AM, Marco Ceppi wrote:
> > Data flow in juju is bi-directional the order does not image or change
> > anything in the relation
>
> Data flow is bi-directional, but my understanding is that a Juju
> interface has the idea of a provider and a consumer, which I think is
> the directionality Ilias is looking for.
>
> Mark
>
>
-- 
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

[Mark Shuttleworth]

On 07/05/2018 11:22 AM, Marco Ceppi wrote:
> Data flow in juju is bi-directional the order does not image or change
> anything in the relation

Data flow is bi-directional, but my understanding is that a Juju
interface has the idea of a provider and a consumer, which I think is
the directionality Ilias is looking for.

Mark

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

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/hadoop-spark-1.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 

Re: Aggregate all bundle.yaml | API endpoint

[Marco Ceppi]

Data flow in juju is bi-directional the order does not image or change
anything in the relation

On Thu, Jul 5, 2018, 10: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/hadoop-spark-1.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

Re: Aggregate all bundle.yaml | API endpoint

[Ilias Tsoumas]

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/hadoop-spark-1.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 

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/hadoop-spark-1.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:
> 

Re: Aggregate all bundle.yaml | API endpoint

[Ilias Tsoumas]

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/hadoop-spark-1.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.jujucharms.com/charmstore/v5/bundle//archive
- download a specific file of a bundle:

 https://api.jujucharms.com/charmstore/v5/bundle//archive/bundle.yaml

Re: juju bootstrap to a particular subnet

[John Meinel]

Can you file a bug about the error message being misleading? It should be
that you get "unknown subnet" not "unknown placement directive".

Thanks,
John
=:->

On Mon, Jul 2, 2018 at 5:06 PM, chris  wrote:

> @John,
>
>   Thanks for confirming it's still there.  I was using the wrong subnet
> mask.  All working now.
>
> Thanks,
> -Chris
>
> On Mon, Jul 2, 2018 at 12:09 AM, John Meinel 
> wrote:
>
>> It should still be available for AWS. I think I saw a case where you
>> might get that error just when it can't find the subnet you asked for (so
>> 'subnet=' is known, but the 172.32.* couldn't be found).
>> I'm not positive about it, but I do still see the subnet matching code in
>> place.
>>
>> John
>> =:->
>>
>>
>> On Mon, Jun 25, 2018 at 11:42 PM, chris  wrote:
>>
>>> Hello everyone,
>>>
>>>   In looking through the docs I was unable to find a way to deploy a
>>> controller to a specific subnet.  I found some old bug reports where there
>>> was possibly a --to directive added to facilitate this back in 2.2.
>>> However, this is what happens when I use it...
>>>
>>> juju bootstrap --config vpc-id=vpc- --credential=cred_name
>>> aws/region controller_name --to subnet=172.32.X.X/20
>>> ERROR failed to bootstrap model: cannot start bootstrap instance:
>>> unknown placement directive: subnet=172.32.X.X/20
>>>
>>>   Is this directive still available?  Has it changed?
>>>
>>> Thanks,
>>> -Chris
>>>
>>> --
>>> 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: Juju 2.4.0 has been released

[Bogdan Kowalczyk]

Fresh install, new box, new controller bootstrapped locally with LXD.

kowalczykb@hp1:~⟫ juju upgrade-juju -m controller 


best version:
2.4.0
started upgrade to 2.4.0


I will see if I can replicate that again later tonight.

--
Kind Regards
Bogdan Kowalczyk

On 03/07/18 12:34, Rick Harding wrote:

On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
bogdan.kowalc...@canonical.com> wrote:


Thanks Vinodhin

I just installed juju from snap and wanted to test couple of deployments.

Should the controller version be 2.4.0 as well or are we keeping 2.3.7?



Is this on an existing deployment? If this controller was already up then
you'll need to make sure to upgrade the controller.

Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for assistance.

Rick



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

Re: Juju 2.4.0 has been released

[Rick Harding]

Sorry, after hitting send I woke up some more and realized what you're
asking. Only the Juju client on your machine is in the snap. The controller
and models need to be manually upgraded. We don't deliver those and auto
upgrade them as a snap.

The proper upgrade doc for the 2.4.0 series is here:
https://docs.jujucharms.com/2.4/en/models-upgrade

Start with the controller and you should be good to go.

On Tue, Jul 3, 2018 at 7:34 AM Rick Harding 
wrote:

> On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
> bogdan.kowalc...@canonical.com> wrote:
>
>> Thanks Vinodhin
>>
>> I just installed juju from snap and wanted to test couple of deployments.
>>
>> Should the controller version be 2.4.0 as well or are we keeping 2.3.7?
>>
>
> Is this on an existing deployment? If this controller was already up then
> you'll need to make sure to upgrade the controller.
>
> Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for
> assistance.
>
> Rick
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.4.0 has been released

[Rick Harding]

Sorry, after hitting send I woke up some more and realized what you're
asking. Only the Juju client on your machine is in the snap. The controller
and models need to be manually upgraded. We don't deliver those and auto
upgrade them as a snap.

The proper upgrade doc for the 2.4.0 series is here:
https://docs.jujucharms.com/2.4/en/models-upgrade

Start with the controller and you should be good to go.

On Tue, Jul 3, 2018 at 7:34 AM Rick Harding 
wrote:

> On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
> bogdan.kowalc...@canonical.com> wrote:
>
>> Thanks Vinodhin
>>
>> I just installed juju from snap and wanted to test couple of deployments.
>>
>> Should the controller version be 2.4.0 as well or are we keeping 2.3.7?
>>
>
> Is this on an existing deployment? If this controller was already up then
> you'll need to make sure to upgrade the controller.
>
> Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for
> assistance.
>
> Rick
>
-- 
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.4.0 has been released

[Rick Harding]

On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
bogdan.kowalc...@canonical.com> wrote:

> Thanks Vinodhin
>
> I just installed juju from snap and wanted to test couple of deployments.
>
> Should the controller version be 2.4.0 as well or are we keeping 2.3.7?
>

Is this on an existing deployment? If this controller was already up then
you'll need to make sure to upgrade the controller.

Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for assistance.

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

Re: Juju 2.4.0 has been released

[Rick Harding]

On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk <
bogdan.kowalc...@canonical.com> wrote:

> Thanks Vinodhin
>
> I just installed juju from snap and wanted to test couple of deployments.
>
> Should the controller version be 2.4.0 as well or are we keeping 2.3.7?
>

Is this on an existing deployment? If this controller was already up then
you'll need to make sure to upgrade the controller.

Check out https://docs.jujucharms.com/1.25/en/juju-upgrade for assistance.

Rick
-- 
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.4.0 has been released

[Bogdan Kowalczyk]

Thanks Vinodhin

I just installed juju from snap and wanted to test couple of deployments.

Should the controller version be 2.4.0 as well or are we keeping 2.3.7?


kowalczykb@hp1:~$ snap list
Name  VersionRev   Tracking  Developer  Notes
core  16-2.33.1  4917  stablecanonical  core
juju  2.4.0  4587  stablecanonical  classic


kowalczykb@hp1:~$ juju status
ModelController  Cloud/Region Version  SLA
default  super-bonkerslocalhost/localhost  2.3.7unsupported

App  Version  Status  Scale  Charm  Store  Rev  OS  Notes

Unit  Workload  Agent  Machine  Public address  Ports  Message

Machine  State  DNS  Inst id  Series  AZ  Message



Thanks
--
Kind Regards

Bogdan Kowalczyk
Technical Account Manager @ Canonical
Email: bogdan.kowalc...@canonical.com

On 03/07/18 10:20, Vinodhini Balusamy wrote:

*Juju team is proud to release version 2.4. This release greatly improves
running and operating production infrastructure at scale. Improvements to
`juju status` output, easier maintenance of proper HA, and guiding Juju to
the correct management network all aid in keeping your infrastructure
running smoothly.  * Bionic supportJuju 2.4 fully supports running
controllers and workloads on Ubuntu 18.04 LTS (Bionic), including
leveraging netplan for network management. * LXD enhancementsLXD
functionality has been updated to support the latest LXD 3.0. Juju supports
LXD installed as a Snap and defaults to Snap-installed LXD by default if it
is present. A basic model of LXD clustering is now supported with the
following conditions: - The juju bootstrap of the localhost cloud must be
performed on a cluster member.- Bridge networking on clustered machines
must be set up to allow egress traffic to the controller container(s).*
Status UX cleanup - ‘Relations’ section in status output has been cleaned
up:- When filtering by application name, only direct relations are shown;-
In tabular format, ‘relations’ section is no longer visible by default (bug
# 1633972 ). Use
‘--relations’ option to see the section.- Clarified empty status output:
whether it is due to a model being empty or because a provided filter did
not match anything on the model (bugs 1255786
, 1696245
 and 1594883
).- Addition of a timestamp
to the status output (bug 1765404
)- Reordering the status
model table to improve consistency between model updates. - Status now
shows application endpoint binding information (in YAML and JSON formats).
For each endpoint, the space to which it is bound is listed.* Controller
configuration options for network spacesTwo new controller configuration
settings have been introduced (see
https://docs.jujucharms.com/2.4/en/controllers-config
). These are: -
juju-mgmt-space- juju-ha-spacejuju-mgmt-space is the name of the network
space used by agents to communicate with controllers. Setting a value for
this item limits the IP addresses of controller API endpoints in agent
config, to those in the space. If the value is misconfigured so as to
expose no addresses to agents, then a fallback to all available addresses
results. Juju client communication with controllers is unaffected by this
value.Juju-ha-space is the name of the network space used for MongoDB
replica-set communication in high availability (HA) setups. This replaces
the previously auto-detected space used for such communication. When
enabling HA, this value must be set where member machines in the HA set
have more than one IP address available for MongoDB use, otherwise an error
will be reported. Existing HA replica sets with multiple available
addresses will report a warning instead of an error provided the members
and addresses remain unchanged.Using either of these options during
bootstrap or enable-ha effectively adds constraints to machine
provisioning. The commands will fail with an error if such constraints
cannot be satisfied.* Rework of 'juju enable-ha'In Juju 2.4 you can no
longer use 'juju enable-ha' to demote controllers. Instead you can now use
the usual 'juju remove-machine X' command, targeting a controller machine.
This will gracefully remove the machine as a controller and from the
database replica set. This method does allow you to end up with an even
number of controllers, which is not a recommended configuration. After
removing a controller it is recommended to run 'juju enable-ha' to bring
back proper redundancy. 'juju remove-machine --force' is also available,
for when the machine is gone and not available to run its own teardown and
cleanup. See https://docs.jujucharms.com/2.4/en/controllers-ha
.* New charming tool:
Charm Goal StateCharm goal state allows charms to discover 

Re: JAAS outage this afternoon

[Casey Marshall]

Service should be restored now. Let us know in #juju on Freenode if you
have any issues, but all should be well.

On Mon, Jul 2, 2018 at 3:36 PM, Casey Marshall  wrote:

> We're currently dealing with an outage this afternoon in JAAS. Users will
> be temporarily unable to add models until it is resolved; however, existing
> models are not impacted.
>
> Will provide an update when status changes. Hopefully will not be too much
> longer..
>
> -Casey
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju bootstrap to a particular subnet

[chris]

@John,

  Thanks for confirming it's still there.  I was using the wrong subnet
mask.  All working now.

Thanks,
-Chris

On Mon, Jul 2, 2018 at 12:09 AM, John Meinel  wrote:

> It should still be available for AWS. I think I saw a case where you might
> get that error just when it can't find the subnet you asked for (so
> 'subnet=' is known, but the 172.32.* couldn't be found).
> I'm not positive about it, but I do still see the subnet matching code in
> place.
>
> John
> =:->
>
>
> On Mon, Jun 25, 2018 at 11:42 PM, chris  wrote:
>
>> Hello everyone,
>>
>>   In looking through the docs I was unable to find a way to deploy a
>> controller to a specific subnet.  I found some old bug reports where there
>> was possibly a --to directive added to facilitate this back in 2.2.
>> However, this is what happens when I use it...
>>
>> juju bootstrap --config vpc-id=vpc- --credential=cred_name
>> aws/region controller_name --to subnet=172.32.X.X/20
>> ERROR failed to bootstrap model: cannot start bootstrap instance: unknown
>> placement directive: subnet=172.32.X.X/20
>>
>>   Is this directive still available?  Has it changed?
>>
>> Thanks,
>> -Chris
>>
>> --
>> 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 bootstrap to a particular subnet

[John Meinel]

It should still be available for AWS. I think I saw a case where you might
get that error just when it can't find the subnet you asked for (so
'subnet=' is known, but the 172.32.* couldn't be found).
I'm not positive about it, but I do still see the subnet matching code in
place.

John
=:->


On Mon, Jun 25, 2018 at 11:42 PM, chris  wrote:

> Hello everyone,
>
>   In looking through the docs I was unable to find a way to deploy a
> controller to a specific subnet.  I found some old bug reports where there
> was possibly a --to directive added to facilitate this back in 2.2.
> However, this is what happens when I use it...
>
> juju bootstrap --config vpc-id=vpc- --credential=cred_name
> aws/region controller_name --to subnet=172.32.X.X/20
> ERROR failed to bootstrap model: cannot start bootstrap instance: unknown
> placement directive: subnet=172.32.X.X/20
>
>   Is this directive still available?  Has it changed?
>
> Thanks,
> -Chris
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm series in API URL

[Timothy Youell]

That makes a lot more sense, thank you Martin. 

If the push to the snap naming system can provide a more useful framework for 
publication, versioning etc then it’s definitely worth going for Mark - it 
would also allow people like me, who are fairly new to the Juju world, to gain 
a better understanding of the interaction between snap and charm. 

Tim

> On 27 Jun 2018, at 10:16, Mark Shuttleworth  wrote:
> 
> 
> Our intention is to shift charm names entirely to the snap naming system. It 
> provides a much more useful approach to publication, versioning, 
> beta/rc/edge, CI/CD.
> 
> So I would ask the store team to make sure that every change they make is a 
> step in that direction, and preferably, that they are lifting wholesale 
> chunks of code from the snap world into the charm world.
> 
> We've learned a lot in the past five years, we should use that ;)
> 
> Mark
> 
> 
> 
> On 06/26/2018 04:46 PM, Martin Hilton wrote:
>> Hi Tim,
>> 
>> The statistics are based on the name of the charm itself. Once upon a time 
>> all charms contained the series in their name. Using your example above 
>> cs:~bigdata-charmers/trusty/hadoop-plugin-5 
>> (https://jujucharms.com/u/bigdata-charmers/hadoop-plugin/trusty/5 
>> ) is a 
>> different charm from cs:~bigdata-charmers/xenial/hadoop-plugin-5 
>> (https://jujucharms.com/u/bigdata-charmers/hadoop-plugin/xenial/5 
>> ). Later 
>> charms are generally multi-series where the series is not included in the 
>> name. For example cs:~bigdata-charmers/hadoop-plugin-35 
>> (https://jujucharms.com/u/bigdata-charmers/hadoop-plugin/35 
>> ). You'll notice 
>> that to get the statistics for the later version of the charm are not 
>> accessible at https://api.jujucharms.com/ 
>> charmstore/v5/stats/counter/archive-download:xenial:hadoop-plugin:bigdata-charmers:35?by=day=2016-04-01=2018-06-20=promulgated,
>>  but can be found at https://api.jujucharms.com/ 
>> charmstore/v5/stats/counter/archive-download::hadoop-plugin:bigdata-charmers:35?by=day=2016-04-01=2018-06-20=promulgated.
>> 
>> cs:~spiculecharms/apache-drill is considered a multi-series charm in this 
>> respect as there is no series in the name.
>> 
>> I hope that clarifies things.
>> ​
>> Martin
>> 
>> 
> 


-- 


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




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

Re: Charm series in API URL

[Mark Shuttleworth]

Our intention is to shift charm names entirely to the snap naming
system. It provides a much more useful approach to publication,
versioning, beta/rc/edge, CI/CD.

So I would ask the store team to make sure that every change they make
is a step in that direction, and preferably, that they are lifting
wholesale chunks of code from the snap world into the charm world.

We've learned a lot in the past five years, we should use that ;)

Mark



On 06/26/2018 04:46 PM, Martin Hilton wrote:
> Hi Tim,
>
> The statistics are based on the name of the charm itself. Once upon a
> time all charms contained the series in their name. Using your example
> above cs:~bigdata-charmers/trusty/hadoop-plugin-5
> (https://jujucharms.com/u/bigdata-charmers/hadoop-plugin/trusty/5) is
> a different charm from cs:~bigdata-charmers/xenial/hadoop-plugin-5
> (https://jujucharms.com/u/bigdata-charmers/hadoop-plugin/xenial/5).
> Later charms are generally multi-series where the series is not
> included in the name. For example
> cs:~bigdata-charmers/hadoop-plugin-35
> (https://jujucharms.com/u/bigdata-charmers/hadoop-plugin/35). You'll
> notice that to get the statistics for the later version of the charm
> are not accessible at
> https://api.jujucharms.com/charmstore/v5/stats/counter/archive-download:xenial:hadoop-plugin:bigdata-charmers:35?by=day=2016-04-01=2018-06-20=promulgated,
> but can be found at
> https://api.jujucharms.com/charmstore/v5/stats/counter/archive-download::hadoop-plugin:bigdata-charmers:35?by=day=2016-04-01=2018-06-20=promulgated.
>
> cs:~spiculecharms/apache-drill is considered a multi-series charm in
> this respect as there is no series in the name.
>
> I hope that clarifies things.
> ​
> Martin
>
>

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

Re: LXD on Manual incorrect resolv.conf

[Tim Penhey]

Am I right in assuming that you are bringing up bionic containers?

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

Re: LXD on Manual incorrect resolv.conf

[Tom Barber]

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


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

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

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

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


Tim

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

-- 


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 

Re: LXD on Manual incorrect resolv.conf

[Tim Penhey]

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

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

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


Tim

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

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

Re: LXD on Manual incorrect resolv.conf

[Tom Barber]

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

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

Juju is 2.3.7

Tom


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

Hi Tom,

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

Also, which version of Juju?

Tim

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

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

-- 


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




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

Re: LXD on Manual incorrect resolv.conf

[Tim Penhey]

Hi Tom,

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

Also, which version of Juju?

Tim

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

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

Re: 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/hadoop-spark-1.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.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
>>>
>>> 

Re: Charm series in API URL

[Martin Hilton]

Hi Tim,

The statistics are based on the name of the charm itself. Once upon a time
all charms contained the series in their name. Using your example above
cs:~bigdata-charmers/trusty/hadoop-plugin-5 (
https://jujucharms.com/u/bigdata-charmers/hadoop-plugin/trusty/5) is a
different charm from cs:~bigdata-charmers/xenial/hadoop-plugin-5 (
https://jujucharms.com/u/bigdata-charmers/hadoop-plugin/xenial/5). Later
charms are generally multi-series where the series is not included in the
name. For example cs:~bigdata-charmers/hadoop-plugin-35 (
https://jujucharms.com/u/bigdata-charmers/hadoop-plugin/35). You'll notice
that to get the statistics for the later version of the charm are not
accessible at https://api.jujucharms.com/charmstore/v5/stats/counter/
archive-download:xenial:hadoop-plugin:bigdata-charmers:35?by=day=2016-
04-01=2018-06-20=promulgated, but can be found at
https://api.jujucharms.com/charmstore/v5/stats/counter/archive-download::
hadoop-plugin:bigdata-charmers:35?by=day=2016-
04-01=2018-06-20=promulgated.

cs:~spiculecharms/apache-drill is considered a multi-series charm in this
respect as there is no series in the name.

I hope that clarifies things.
​
Martin
-- 
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

[Ilias Tsoumas]

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/hadoop-spark-1.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.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: 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: adding nics to a vm in vmware built by juju deploy

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

[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

Re: Juju 2.4-rc2 has been released

[Rick Harding]

I want to make sure it's clear that this is the last exected RC release. If
no issues are found in testing from the community we plan on a final
release next week. Please give it a spin attempt to crush it for all your
worth!

Thanks!

On Mon, Jun 18, 2018 at 6:36 PM Chris Lee 
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *A new development release of Juju is here, 2.4-rc2.## Fixes - A bug
> introduced in RC1 for the Oracle and Joyent providers has been
> corrected.For a list of all bugs fixed in this release,
> seehttps://launchpad.net/juju/+milestone/2.4-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). sudo snap install juju --classic --candidateOther 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 amessage on Twitter using #jujucharms, join us at #juju on
> freenode, and subscribe to the mailing list at juju@lists.ubuntu.com
> .## More informationTo 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.4-rc2 has been released

[Rick Harding]

I want to make sure it's clear that this is the last exected RC release. If
no issues are found in testing from the community we plan on a final
release next week. Please give it a spin attempt to crush it for all your
worth!

Thanks!

On Mon, Jun 18, 2018 at 6:36 PM Chris Lee 
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *A new development release of Juju is here, 2.4-rc2.## Fixes - A bug
> introduced in RC1 for the Oracle and Joyent providers has been
> corrected.For a list of all bugs fixed in this release,
> seehttps://launchpad.net/juju/+milestone/2.4-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). sudo snap install juju --classic --candidateOther 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 amessage on Twitter using #jujucharms, join us at #juju on
> freenode, and subscribe to the mailing list at j...@lists.ubuntu.com
> .## More informationTo 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: adding nics to a vm in vmware built by juju deploy

[Rick Harding]

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

[Rick Harding]

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

[Cory Johns]

Merlijn,

cs:mattermost (https://jujucharms.com/mattermost/) has been promulgated
from cs:~tengu-team/mattermost

Thanks!

On Sat, Jun 16, 2018 at 7:31 PM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> 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

Re: EC2 availability zones and bundles

[George Kraft]

Thanks Tim. I went ahead and opened a bug for this:
https://bugs.launchpad.net/juju/+bug/1777487

Cheers,
George Kraft

On Sun, Jun 17, 2018 at 6:28 PM, Tim Penhey 
wrote:

> I don't believe this is possible with bundles at the moment.
>
> The only placement directives that is currently supported in bundles are:
>   
>   new
>   lxd:new
>   lxd:
>   kvm:new
>   kvm:
>
> I *think* that is it.
>
> Tim
>
> On 16/06/18 05:57, George Kraft wrote:
> > Hey folks,
> >
> > Is there a way to assign units or machines to specific availability
> > zones on EC2 when deploying from a bundle?
> >
> > I see there's a way to do it for standalone machines/units with either
> > of the following:
> >
> > juju add-machine zone=us-east-1c
> > juju deploy ubuntu --to zone=us-east-1c
> >
> > But I'm having trouble finding any way to do it in a bundle. For
> > example, I can't use the above placement directive in a bundle:
> >
> > $ cat test.yaml
> > services:
> >   ubuntu:
> > charm: "cs:ubuntu"
> > num_units: 1
> > to:
> > - "zone=us-east-1c"
> > $ juju deploy ./test.yaml
> > ERROR cannot deploy bundle: the provided bundle has the following errors:
> > invalid placement syntax "zone=us-east-1c"
> >
> > Anyone know if there's a way to do it?
> >
> > Thanks,
> > George Kraft
> >
> >
>
> --
> 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: EC2 availability zones and bundles

[Tim Penhey]

I don't believe this is possible with bundles at the moment.

The only placement directives that is currently supported in bundles are:
  
  new
  lxd:new
  lxd:
  kvm:new
  kvm:

I *think* that is it.

Tim

On 16/06/18 05:57, George Kraft wrote:
> Hey folks,
> 
> Is there a way to assign units or machines to specific availability
> zones on EC2 when deploying from a bundle?
> 
> I see there's a way to do it for standalone machines/units with either
> of the following:
> 
> juju add-machine zone=us-east-1c
> juju deploy ubuntu --to zone=us-east-1c
> 
> But I'm having trouble finding any way to do it in a bundle. For
> example, I can't use the above placement directive in a bundle:
> 
> $ cat test.yaml
> services:
>   ubuntu:
>     charm: "cs:ubuntu"
>     num_units: 1
>     to:
>     - "zone=us-east-1c"
> $ juju deploy ./test.yaml
> ERROR cannot deploy bundle: the provided bundle has the following errors:
> invalid placement syntax "zone=us-east-1c"
> 
> Anyone know if there's a way to do it?
> 
> Thanks,
> George Kraft
> 
> 

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

Re: Please promulgate Mattermost charm

[Marco Ceppi]

Oi, egg on face I confused mattermost with matrix, carry on.

On Sun, Jun 17, 2018, 15:46 Merlijn Sebrechts 
wrote:

> 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 <
>> merlijn.sebrec...@gmail.com> 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

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

Re: Please promulgate Mattermost charm

[Marco Ceppi]

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

Re: How do you clean a juju disk or make it larger?

[Rick Harding]

Thanks for the added detail Daniel. Glad you got the resize worked out.

On Wed, Jun 13, 2018 at 9:36 AM Daniel Bidwell  wrote:

> My case was using VmWare as the cloud.  The controllers defaulted to
> 10GB.  I am running juju 2.3.8.  I have about 12 vm's on the controller
> with about 24 locally written charms.  /var/lib/juju/db is currently
> using 8.3GB.
>
> The simplest solution for me was to increase the root disk size and
> reboot the controller.  The cloud-init process resized the partition to
> fill the rest of the disk and then resized the file system to fill the
> enlarged partition.
>
> I am not concerned about the size so much as I needed to finish
> deploying my spread of servers.
>
> I did clean out a group of old kernels that had accumulated as well as
> old versions of juju that I had upgraded from, but those were
> incidental.
>
> I posted the question and solution to askubuntu.com so others could
> find the answer easily if they hit the same problem.
>
> On Wed, 2018-06-13 at 16:06 +0400, John Meinel wrote:
> > IIRC older Juju used the default EC2 settings, which gave 8GB hard
> > drives, but newer should default to 32GB disks. I'm not sure how that
> > varies across all providers, though.
> >
> > Note that you should always be able to bootstrap with a custom root-
> > disk constraint. eg "juju bootstrap --bootstrap-constraints root-
> > disk=32G"
> >
> > As for issues about the disk filling up, it would be good to have a
> > bit more information about what juju version, what types of workloads
> > you're deploying, etc. The data might be stale charm binaries that
> > are being cached by the server, or if it is Juju 1.X then it could be
> > image caches, or transaction log issues, etc.
> >
> > John
> > =:->
> >
> > On Tue, Jun 12, 2018 at 9:12 AM, Paul Gear 
> > wrote:
> > > On 11/06/18 01:47, Daniel Bidwell wrote:
> > > > My juju controllers appear to be defaulting to a 10GB root disk.
> > > I am
> > > > running out of disk space on the controller. I have 6.7GB in
> > > > /var/lib/juju/db. Is there a way to reduce the disk usage on
> > > this?
> > >
> > > I think perhaps this is worth logging as a wishlist bug. A long-
> > > running
> > > production juju controller should never be deployed with a disk
> > > that
> > > small (our largest production cluster is already a little
> > > uncomfortable
> > > with 50 GB), and juju doesn't really distinguish between "this is a
> > > CI
> > > controller that's only going to be up long enough to run my test
> > > suite"
> > > and "this is going to run all of my production OpenStack VMs for
> > > the
> > > next year". It would be nice if you could tell it "size the
> > > controller
> > > for N live models".
> > >
> > > > If not, can I make the root disk larger? What are my options?
> > >
> > > That all depends on your underlying cloud infrastructure.  I
> > > believe
> > > some providers (e.g. GCE) make this really easy.
> > >
> > > > I have already cleared out kernel updates.
> > >
> > > Not directly related to juju controller sizing, but relevant to the
> > > above: I've been working on a little tool that handles many of the
> > > common scenarios we encounter, including kernel updates and other
> > > tools
> > > you may or may not use.  It's alpha quality; feedback & patches
> > > gratefully accepted:
> > >
> > > https://code.launchpad.net/~paulgear/+git/cleanup
> > >
> > > --
> > > Regards,
> > > Paul Gear
> > > Site Reliability Engineer
> > > Canonical - Information Systems
> > >
> > >
> > > --
> > > Juju mailing list
> > > Juju@lists.ubuntu.com
> > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman
> > > /listinfo/juju
> > >
> --
> Daniel Bidwell 
>
>
> --
> 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 do you clean a juju disk or make it larger?

[Daniel Bidwell]

My case was using VmWare as the cloud.  The controllers defaulted to
10GB.  I am running juju 2.3.8.  I have about 12 vm's on the controller
with about 24 locally written charms.  /var/lib/juju/db is currently
using 8.3GB.

The simplest solution for me was to increase the root disk size and
reboot the controller.  The cloud-init process resized the partition to
fill the rest of the disk and then resized the file system to fill the
enlarged partition.

I am not concerned about the size so much as I needed to finish
deploying my spread of servers.

I did clean out a group of old kernels that had accumulated as well as
old versions of juju that I had upgraded from, but those were
incidental.

I posted the question and solution to askubuntu.com so others could
find the answer easily if they hit the same problem.

On Wed, 2018-06-13 at 16:06 +0400, John Meinel wrote:
> IIRC older Juju used the default EC2 settings, which gave 8GB hard
> drives, but newer should default to 32GB disks. I'm not sure how that
> varies across all providers, though.
> 
> Note that you should always be able to bootstrap with a custom root-
> disk constraint. eg "juju bootstrap --bootstrap-constraints root-
> disk=32G"
> 
> As for issues about the disk filling up, it would be good to have a
> bit more information about what juju version, what types of workloads
> you're deploying, etc. The data might be stale charm binaries that
> are being cached by the server, or if it is Juju 1.X then it could be
> image caches, or transaction log issues, etc.
> 
> John
> =:->
> 
> On Tue, Jun 12, 2018 at 9:12 AM, Paul Gear 
> wrote:
> > On 11/06/18 01:47, Daniel Bidwell wrote:
> > > My juju controllers appear to be defaulting to a 10GB root disk.
> > I am
> > > running out of disk space on the controller. I have 6.7GB in 
> > > /var/lib/juju/db. Is there a way to reduce the disk usage on
> > this?
> > 
> > I think perhaps this is worth logging as a wishlist bug. A long-
> > running
> > production juju controller should never be deployed with a disk
> > that
> > small (our largest production cluster is already a little
> > uncomfortable
> > with 50 GB), and juju doesn't really distinguish between "this is a
> > CI
> > controller that's only going to be up long enough to run my test
> > suite"
> > and "this is going to run all of my production OpenStack VMs for
> > the
> > next year". It would be nice if you could tell it "size the
> > controller
> > for N live models".
> > 
> > > If not, can I make the root disk larger? What are my options?
> > 
> > That all depends on your underlying cloud infrastructure.  I
> > believe
> > some providers (e.g. GCE) make this really easy.
> > 
> > > I have already cleared out kernel updates.
> > 
> > Not directly related to juju controller sizing, but relevant to the
> > above: I've been working on a little tool that handles many of the
> > common scenarios we encounter, including kernel updates and other
> > tools
> > you may or may not use.  It's alpha quality; feedback & patches
> > gratefully accepted:
> > 
> > https://code.launchpad.net/~paulgear/+git/cleanup
> > 
> > -- 
> > Regards,
> > Paul Gear
> > Site Reliability Engineer
> > Canonical - Information Systems
> > 
> > 
> > -- 
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman
> > /listinfo/juju
> > 
-- 
Daniel Bidwell 


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

Re: How do you clean a juju disk or make it larger?

[John Meinel]

IIRC older Juju used the default EC2 settings, which gave 8GB hard drives,
but newer should default to 32GB disks. I'm not sure how that varies across
all providers, though.

Note that you should always be able to bootstrap with a custom root-disk
constraint. eg "juju bootstrap --bootstrap-constraints root-disk=32G"

As for issues about the disk filling up, it would be good to have a bit
more information about what juju version, what types of workloads you're
deploying, etc. The data might be stale charm binaries that are being
cached by the server, or if it is Juju 1.X then it could be image caches,
or transaction log issues, etc.

John
=:->

On Tue, Jun 12, 2018 at 9:12 AM, Paul Gear  wrote:

> On 11/06/18 01:47, Daniel Bidwell wrote:
> > My juju controllers appear to be defaulting to a 10GB root disk. I am
> > running out of disk space on the controller. I have 6.7GB in
> > /var/lib/juju/db. Is there a way to reduce the disk usage on this?
>
> I think perhaps this is worth logging as a wishlist bug. A long-running
> production juju controller should never be deployed with a disk that
> small (our largest production cluster is already a little uncomfortable
> with 50 GB), and juju doesn't really distinguish between "this is a CI
> controller that's only going to be up long enough to run my test suite"
> and "this is going to run all of my production OpenStack VMs for the
> next year". It would be nice if you could tell it "size the controller
> for N live models".
>
> > If not, can I make the root disk larger? What are my options?
>
> That all depends on your underlying cloud infrastructure.  I believe
> some providers (e.g. GCE) make this really easy.
>
> > I have already cleared out kernel updates.
>
> Not directly related to juju controller sizing, but relevant to the
> above: I've been working on a little tool that handles many of the
> common scenarios we encounter, including kernel updates and other tools
> you may or may not use.  It's alpha quality; feedback & patches
> gratefully accepted:
>
> https://code.launchpad.net/~paulgear/+git/cleanup
>
> --
> Regards,
> Paul Gear
> Site Reliability Engineer
> Canonical - Information Systems
>
>
> --
> 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: Mongo DB on the Juju controller

[Giu Platania]

Thank you Sandor,
using that page I managed to connect to the MongoDB instance!

From: Sandor Zeestraten 
Sent: June 12, 2018 2:28 PM
To: Giu Platania 
Cc: juju 
Subject: Re: Mongo DB on the Juju controller

Hey Giu, the juju wiki on GitHub has some details on how to login into mongodb.

https://github.com/juju/juju/wiki/Login-into-MongoDB

Cheers
--
Sandor Zeestraten

On Tue, Jun 12, 2018, 19:18 Giu Platania 
mailto:giu.plata...@cloudgensys.com>> wrote:
All,
We are trying to access the MongoDB instance within the juju controller.
What is the admin password for it?
The standard Ubuntu Sudo user is not working
Thanks

--

Giu Platania
TOGAF certified Enterprise Architect
email: giu.plata...@cloudgensys.com<mailto:giu.plata...@cloudgensys.com>
Cell: +1 902 748 0992
Profile: http://www.linkedin.com/profile/view?id=119360308

--
Juju mailing list
Juju@lists.ubuntu.com<mailto: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: Mongo DB on the Juju controller

[Sandor Zeestraten]

Hey Giu, the juju wiki on GitHub has some details on how to login into
mongodb.

https://github.com/juju/juju/wiki/Login-into-MongoDB

Cheers
--
Sandor Zeestraten

On Tue, Jun 12, 2018, 19:18 Giu Platania 
wrote:

> All,
>
> We are trying to access the MongoDB instance within the juju controller.
>
> What is the admin password for it?
>
> The standard Ubuntu Sudo user is not working
>
> Thanks
>
> --
>
>
> Giu Platania
> TOGAF certified Enterprise Architect
> email: giu.plata...@cloudgensys.com
> Cell: +1 902 748 0992
> Profile: http://www.linkedin.com/profile/view?id=119360308
>
>
> --
> 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: 18.05 OpenStack Charms release

[Nobuto Murata]

2018年6月12日(火) 12:25 David Ames :

> Announcing the 18.05 release of the OpenStack Charms.
>
> The 18.05 charms have full support for the Bionic Ubuntu series.
> Encryption at rest has been implemented in the storage charms.
> In addition, the vault and neutron-dynamic-routing charms have been
> introduced. 72 bugs have been fixed and released across the OpenStack
> charms.
>
> For full details of the release, please refer to the release notes:
>
>   https://docs.openstack.org/charm-guide/latest/18.05.html


18.05 without a dot in the URL :-)
https://docs.openstack.org/charm-guide/latest/1805.html



>
> Thanks go to the following contributors for this release:
>
> Alex Kavanagh
> Andrew McLeod
> Ante Karamatić
> Billy Olsen
> Chris MacNaughton
> Chris Sanders
> Corey Bryant
> Craige McWhirter
> David Ames
> Drew Freiberger
> Edward Hope-Morley
> Felipe Reyes
> Frode Nordahl
> Fulvio Galeazzi
> Jakub Rohovsky
> James Hebden
> James Page
> Liam Young
> Mario Splivalo
> Michael Skalka
> Peter Sabaini
> Ryan Beisner
> Sean Feole
> Seyeong Kim
> Tamas Erdei
> Tytus Kurek
> Xav Paice
> viswesuwara nathan
>
> --
> 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 2.4-rc1 Released

[Marco Ceppi]

Eagerly awaiting remote LXD clusters :)

On Thu, Jun 7, 2018 at 10:52 AM Rick Harding 
wrote:

> Not yet. This enables bootstrapping on a clustered lxd that's also
> localhost. It's a step toward making Juju aware of the clustering APIs but
> does not yet enable the work of adding a remote lxd cloud. I showed this in
> last week's Juju show.
>
> https://youtu.be/CidoBy3iqUw
>
> On Wed, Jun 6, 2018, 6:58 PM Marco Ceppi 
> wrote:
>
>> On Wed, Jun 6, 2018, 21:33 Kelvin Liu  wrote:
>>
>>>
>>>
>>>
>>>
>>> *A new development release of Juju is here, 2.4-rc1.## New and Improved
>>> - LXD functionality has been updated to support version 3 of LXD. Better
>>> support exists for LXD installed as a Snap, defaulting to Snap-installed
>>> LXD by default if it is present. Initial support for LXD clustering is
>>> available under constrained conditions:*
>>>
>>
>> Does this mean that I can bootstrap a remote LXD cluster now?
>>
> --
>> 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.4-rc1 Released

[Marco Ceppi]

Eagerly awaiting remote LXD clusters :)

On Thu, Jun 7, 2018 at 10:52 AM Rick Harding 
wrote:

> Not yet. This enables bootstrapping on a clustered lxd that's also
> localhost. It's a step toward making Juju aware of the clustering APIs but
> does not yet enable the work of adding a remote lxd cloud. I showed this in
> last week's Juju show.
>
> https://youtu.be/CidoBy3iqUw
>
> On Wed, Jun 6, 2018, 6:58 PM Marco Ceppi 
> wrote:
>
>> On Wed, Jun 6, 2018, 21:33 Kelvin Liu  wrote:
>>
>>>
>>>
>>>
>>>
>>> *A new development release of Juju is here, 2.4-rc1.## New and Improved
>>> - LXD functionality has been updated to support version 3 of LXD. Better
>>> support exists for LXD installed as a Snap, defaulting to Snap-installed
>>> LXD by default if it is present. Initial support for LXD clustering is
>>> available under constrained conditions:*
>>>
>>
>> Does this mean that I can bootstrap a remote LXD cluster now?
>>
> --
>> 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: Juju 2.4-rc1 Released

[Rick Harding]

Not yet. This enables bootstrapping on a clustered lxd that's also
localhost. It's a step toward making Juju aware of the clustering APIs but
does not yet enable the work of adding a remote lxd cloud. I showed this in
last week's Juju show.

https://youtu.be/CidoBy3iqUw

On Wed, Jun 6, 2018, 6:58 PM Marco Ceppi  wrote:

> On Wed, Jun 6, 2018, 21:33 Kelvin Liu  wrote:
>
>>
>>
>>
>>
>> *A new development release of Juju is here, 2.4-rc1.## New and Improved -
>> LXD functionality has been updated to support version 3 of LXD. Better
>> support exists for LXD installed as a Snap, defaulting to Snap-installed
>> LXD by default if it is present. Initial support for LXD clustering is
>> available under constrained conditions:*
>>
>
> Does this mean that I can bootstrap a remote LXD cluster now?
> --
> 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: Juju 2.4-rc1 Released

[Rick Harding]

Not yet. This enables bootstrapping on a clustered lxd that's also
localhost. It's a step toward making Juju aware of the clustering APIs but
does not yet enable the work of adding a remote lxd cloud. I showed this in
last week's Juju show.

https://youtu.be/CidoBy3iqUw

On Wed, Jun 6, 2018, 6:58 PM Marco Ceppi  wrote:

> On Wed, Jun 6, 2018, 21:33 Kelvin Liu  wrote:
>
>>
>>
>>
>>
>> *A new development release of Juju is here, 2.4-rc1.## New and Improved -
>> LXD functionality has been updated to support version 3 of LXD. Better
>> support exists for LXD installed as a Snap, defaulting to Snap-installed
>> LXD by default if it is present. Initial support for LXD clustering is
>> available under constrained conditions:*
>>
>
> Does this mean that I can bootstrap a remote LXD cluster now?
> --
> 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.4-rc1 Released

[Marco Ceppi]

On Wed, Jun 6, 2018, 21:33 Kelvin Liu  wrote:

>
>
>
>
> *A new development release of Juju is here, 2.4-rc1.## New and Improved -
> LXD functionality has been updated to support version 3 of LXD. Better
> support exists for LXD installed as a Snap, defaulting to Snap-installed
> LXD by default if it is present. Initial support for LXD clustering is
> available under constrained conditions:*
>

Does this mean that I can bootstrap a remote LXD cluster now?
-- 
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

[Ilias Tsoumas]

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.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: 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: Major Roadblocks - real life use cases

[Tom Barber]

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


Tom


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

Drew,

Thanks for the response.

I've been dabbling in these areas.

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

~James



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

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

-- 


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




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

Re: Major Roadblocks - real life use cases

[James Beedy]

Drew,

Thanks for the response.

I've been dabbling in these areas.

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

~James



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

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

Re: Major Roadblocks - real life use cases

[Drew Freiberger]

On Mon, May 28, 2018 at 10:23:21PM -0700, James Beedy wrote:

I want to shed some light on a few blockers for me right now.

2) Maas needs better support for 3rd party drivers.
 * Getting my Mellanox drivers hooked up at commissioning so maas 
recognizes the 40Gb interfaces is taking me a few weeks now. Supporting user 
defined 3rd party driver should be a primary supported capability of MAAS.
 * how are people doing Hadoop,and Ceph and Openstack without this, 
possibly someone knows something I don’t know here?


Hello James,

I believe that MAAS 2.x's nodes-scripts (Hardware Testing and
Commissioning scripts) might be helpful for any custom code or
drivers you might want to inject in the commissioning process.

Here is a link to the guide for these scripts.  I might suggest
the cript example for "Configure HPA" might provide a good template for
how you might want to inject a Mellanox driver/config into your build.

https://docs.maas.io/2.3/en/nodes-scripts

The MAAS server has a web server serving out a docroot from
/var/www/htdocs where you can drop any files you might want to curl/wget
from your scripts.  I believe there are environment variables for the
preseeds for the IP of the MAAS server for your URL.

You might also notice that you can have the script automatically install
packages from any of apt, snap, or URL.  You can even tag the script to
automatically run on hardware with a specific PCI ID. with the
for_hardware metadata field.

Documentation on managing these scripts via the CLI is here:

https://docs.maas.io/2.3/en/nodes-scripts-cli

In MAAS 1 environments, one would have to update the curtin preseeds
manually in /etc/maas/preseeds to inject scripts of this type.

I do not know if the commissioning scripts also happen at deployment
time (doubtful), but hopefully the install of your chosen OS will
include the drivers needed, or you've found that you can add an Ubuntu
package repository or PPA that contains your packages to be installed
per https://docs.maas.io/2.3/en/manage-repos.

I hope this information helps.

Sincerely,
-Drew


Any feedback would be greatly appreciated.

Thanks



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


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

Re: SLURM Charms New Upstream

[Kevin Monroe]

Hey James!

You asked for re-promulgation, but I don't see any existing promulgated
slurm charms (https://jujucharms.com/q/slurm).  I'm happy to promulgate the
~omnivector releases, but I noticed you're also a member of ~slurm-charmers
(https://launchpad.net/~slurm-charmers/+members), which also has releases
for these charms.

Please confirm which namespace you want promulgated -- either here or via
chat on the internet relay.

Thanks!
-Kevin

On Mon, May 21, 2018 at 11:48 AM, James Beedy <jamesbe...@gmail.com> wrote:

> Request to have the 'slurm-node', and 'slurm-controller' charms
> re-promulgated under the omnivector org namespace.
>
> The new charm locations are
>
> cs:~omnivector/slurm-node
>
> cs:~omnivector/slurm-controller
>
> 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: Juju, OpenStack and Packet.net @KubeCon Copenhagen

[Marco Ceppi]

Hi Andrej,

I'll send you an email off list, glad you enjoyed the demo!

Marco

On Tue, May 22, 2018 at 5:25 AM Andrej Golis  wrote:

> Hi community,
>
> I had a chance to see Juju in action deploying OpenStack on
> Packet.net's ARM9 96-core system, which looked pretty cool :)
>
> Unfortunately I lost a connection with the guy who was presenting it -
> does anyone know him and could possibly let him know to get in touch
> with me?
>
> Much appreciated, thanks :)
>
> Kind regards / S pozdravom,
> --
> Andrej Golis | RHCA III
> andrej.go...@gmail.com
> https://www.linkedin.com/in/agolis
>
> --
> 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: Additional bindings

[Mark Shuttleworth]

On 05/18/2018 06:26 AM, Vidmantas Rinkevičius wrote:
> Thank, you. Worked like a charm. 

That's how we like it :)

Mark

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

Re: Additional bindings

[Vidmantas Rinkevičius]

Thank, you. Worked like a charm.


On 2018-05-17 23:59, Xav Paice wrote:

"": admin


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

Re: Additional bindings

[Xav Paice]

What you could try is to add:

bindings:
  "": admin
  public: storage
  cluster: internal

That way, your defualt binding is to the admin space.

On Thu, May 17, 2018 at 11:44:55PM +0300, Vidmantas Rinkevičius wrote:
> Hi,
> 
> I am facing issue where I need additional network bindings in my deployment.
> I tried to add extra bind, but it looks like binds are hard coded.
> 
> services:
>   ceph-mon:
>     annotations:
>   gui-x: '750'
>   gui-y: '500'
>     charm: cs:~openstack-charmers-next/bionic/ceph-mon
>     num_units: 3
>     bindings:
>   public: storage
>   cluster: internal
>     extra-bindings:
>    admin: admin
>     options:
>   expected-osd-count: 3
>   source: proposed
>     to:
>     - lxd:6
>     - lxd:7
>     - lxd:8
> 
> After this I get error:
> 
> 23:28:44 DEBUG juju.api monitor.go:35 RPC connection died
> ERROR cannot deploy bundle: cannot deploy application "ceph-osd": invalid
> binding(s) supplied "admin", valid binding names are "cluster", "mon",
> "nrpe-external-master", "public", "secrets-storage"
> 
> I added admin bind with so that deployed container would have a vlan for
> admin. I have space defined so I assume issue is with bind name not being
> accepted.
> 
> -- 
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju


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

Re: SSH to machines from add-user

[Rick Harding]

I worked with Tom on this in IRC and got to the bottom of it. We hit a
corner case of the superuser. The folks that own the controller themselves
are a bit special. While technically they're the boss and can juju status
any model in the controller, they don't see all the models by default in
juju models and the like. It'd make being the controller admins a real
pain.

Likewise, we don't auto add the ssh key of every superuser to every machine
in every model regardless of the owner. We take the tact that supserusers
can sudo around and do anything, but by default commands only allow them to
do things on models they've been given model level access to directly.

Tom was setting up a controller, adding a user, and granting them superuser
on the controller. However, as the user had no direct share/access to the
model in question it could not ssh to the machines in the model.

I think we can be more clear here around the error messaging as we know the
user is a superuser and why the request failed.

On Fri, May 11, 2018 at 6:11 AM Tom Barber  wrote:

> Hello folks
>
> IRC has failed me so lets try the wider world.
>
> We have a multinode manual cloud deployed. We have juju add-user 2 new
> users and also juju add-ssh-key for those users.
>
> We know the ssh key works because
>
> ssh ubuntu@
>
> works fine and we can sudo -i etc and do stuff.
>
> But
>
> juju ssh 
>
> says:
>
> ERROR permission denied (unauthorized access)
> 11:05:18 DEBUG cmd supercommand.go:459 error stack:
> permission denied (unauthorized access)
> github.com/juju/juju/rpc/client.go:149:
> github.com/juju/juju/api/apiclient.go:924:
> github.com/juju/juju/api/sshclient/facade.go:109:
> github.com/juju/juju/cmd/juju/commands/ssh_common.go:257:
> github.com/juju/juju/cmd/juju/commands/ssh_common.go:141:
> github.com/juju/juju/cmd/juju/commands/ssh.go:117:
>
> I've looked at the code and it claims we can
>
> juju ssh ubuntu@ -i 
>
> that fails with the same error.
>
> If I tail the target servers auth.log there isn't even a failed login
> attempt which strikes me as a little weird considering it says
>
> permission denied (unauthorized access)
>
> Which does make me question... what permission is denied?
>
>
> --
>
>
> Spicule Limited is registered in England & Wales. Company Number:
> 09954122. Registered office: First Floor, Telecom House, 125-135 Preston
> Road, Brighton, England, BN1 6AF. VAT No. 251478891.
>
>
>
>
> All engagements
> are subject to Spicule Terms and Conditions of Business. This email and
> its
> contents are intended solely for the individual to whom it is addressed
> and
> may contain information that is confidential, privileged or otherwise
> protected from disclosure, distributing or copying. Any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of Spicule Limited. The company accepts no
> liability for any damage caused by any virus transmitted by this email. If
> you have received this message in error, please notify us immediately by
> reply email before deleting it from your system. Service of legal notice
> cannot be effected on Spicule Limited by email.
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Blog post about expanding Ceph clusters with Juju

[Nick Veitch]

That's a great walkthrough. Thanks for sharing it  - and including plenty
of links!


On 9 May 2018 at 10:37, Sandor Zeestraten  wrote:

> Hey Juju folks, I wrote up a short blog post about expanding Ceph clusters
> with Juju in case anyone is interested and looking to do the same.
>
> https://zeestrataca.com/posts/expanding-ceph-clusters-with-juju/
>
> Cheers
> --
> Sandor Zeestraten
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


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

Re: canonical-kubernetes - Adding worker get stuck

[Tim Van Steenburgh]

Please post an issue at
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/new

The issue template contains instructions for gathering debug info from the
cluster.

On Fri, Apr 27, 2018 at 11:37 AM, sSeBBaSs  wrote:

> Hi Guys,
>
> Today I was able to correctly deploy a kubernetes-cluster, but somehow it
> seems that adding a worker fail, here you have an extract of the juju
> debug-log
>
> 2018-04-27 15:30:23 INFO juju-log Reactive main running for hook update-status
> 2018-04-27 15:30:24 INFO juju-log Initializing Snap Layer
> 2018-04-27 15:30:24 DEBUG update-status none
> 2018-04-27 15:30:24 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:257:charm_status
> 2018-04-27 15:30:24 INFO juju-log Invoking reactive handler: 
> reactive/docker.py:341:enable_grub_cgroups
> 2018-04-27 15:30:24 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:301:send_data
> 2018-04-27 15:30:25 INFO juju-log Invoking reactive handler: 
> reactive/tls_client.py:60:store_client
> 2018-04-27 15:30:25 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:234:set_app_version
> 2018-04-27 15:30:25 INFO juju-log Invoking reactive handler: 
> reactive/tls_client.py:15:store_ca
> 2018-04-27 15:30:25 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:977:catch_change_in_creds
> 2018-04-27 15:30:26 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:965:request_kubelet_and_proxy_credentials
> 2018-04-27 15:30:26 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:956:notify_master_gpu_not_enabled
> 2018-04-27 15:30:26 INFO juju-log Setting gpu=False on kube-control relation
> 2018-04-27 15:30:26 INFO juju-log Invoking reactive handler: 
> reactive/tls_client.py:36:store_server
> 2018-04-27 15:30:26 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:1007:fix_iptables_for_docker_1_13
> 2018-04-27 15:30:26 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:424:apply_node_labels
> 2018-04-27 15:30:27 INFO juju-log Skipping malformed option: .
> 2018-04-27 15:30:27 DEBUG update-status Error from server (NotFound): nodes 
> "ip-10-0-3-204.ec2.internal" not found
> 2018-04-27 15:30:27 INFO juju-log Failed to apply label 
> juju-application=kubernetes-worker. Will retry.
> 2018-04-27 15:30:28 DEBUG update-status Error from server (NotFound): nodes 
> "ip-10-0-3-204.ec2.internal" not found
> 2018-04-27 15:30:28 INFO juju-log Failed to apply label 
> juju-application=kubernetes-worker. Will retry.
> 2018-04-27 15:30:29 DEBUG update-status Error from server (NotFound): nodes 
> "ip-10-0-3-204.ec2.internal" not found
> 2018-04-27 15:30:29 INFO juju-log Failed to apply label 
> juju-application=kubernetes-worker. Will retry.
> 2018-04-27 15:30:30 DEBUG update-status Error from server (NotFound): nodes 
> "ip-10-0-3-204.ec2.internal" not found
> 2018-04-27 15:30:30 INFO juju-log Failed to apply label 
> juju-application=kubernetes-worker. Will retry.
>
> Any thoughts?
> ​
> --
> ---
> Sebastian Juárez
> Mail: ssebb...@gmail.com
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Error conjure-up canonical-kubernetes

[Tim Van Steenburgh]

I've hit this too (https://github.com/conjure-up/conjure-up/issues/1392).
The important bit from the log is:

2018-04-26 16:42:13,390 [ERROR] conjure-up/canonical-kubernetes -
juju.py:741 - cannot change profile for the next exec call: No such file or
directory
The error happens when conjure-up runs the juju-wait snap. In my case, the
problem just went away. At the time there had been some issues with the
core snap, so I just chalked it up to that and moved on.

Other similar reports I've seen:

https://bugs.launchpad.net/snappy/+bug/1687079
https://bugs.launchpad.net/snapcraft/+bug/1760514

If the problem continues I'd suggest opening a bug against conjure-up or
snappy. Either way we'll likely need help from the snappy team to debug and
resolve this.

On Thu, Apr 26, 2018 at 3:46 PM, sSeBBaSs  wrote:

> Hi Guys!
>
> I’m trying to deploy a clean kubernetes cluster with conjure-up, but since
> today I’m having this issue:
>
> conjure-up canonical-kubernetes aws juju-test-controller00 kube00
> [info] Summoning canonical-kubernetes to aws
> [info] Connecting to Juju model kube00...
> [info] Juju model connected.
> [info] Running Canonical Distribution of Kubernetes step: 
> 00_process-providertype before-deploy.
> [info] Deploying Applications.
> [info] Waiting for deployment to settle.
> [error] Some applications failed to start successfully.
> [warning] Shutting down
>
> And from the conjure-up log:
>
> 2018-04-26 16:41:15,037 [DEBUG] conjure-up/_unspecified_spell - juju.py:34 - 
> bin_path candidate found
> 2018-04-26 16:41:15,038 [DEBUG] conjure-up/_unspecified_spell - juju.py:34 - 
> wait_path candidate found
> 2018-04-26 16:41:15,132 [DEBUG] conjure-up/_unspecified_spell - app.py:263 - 
> Juju version: 2.3.7-xenial-amd64, conjure-up version: 2.5.6
> 2018-04-26 16:41:15,144 [DEBUG] conjure-up/_unspecified_spell - app.py:346 - 
> found spell {'key': 'canonical-kubernetes', 'name': 'Canonical Distribution 
> of Kubernetes', 'description': 'Kubernetes is an open-source platform for 
> deploying, scaling, and operations of application containers across a cluster 
> of hosts. Kubernetes is portable in that it works with public, private, and 
> hybrid clouds. Extensible through a pluggable infrastructure. Self healing in 
> that it will automatically restart and place containers on healthy nodes if a 
> node ever goes away.\n'}
> 2018-04-26 16:41:15,144 [DEBUG] conjure-up/_unspecified_spell - 
> telemetry.py:31 - Spell Choice: canonical-kubernetes
> 2018-04-26 16:41:15,156 [DEBUG] conjure-up/canonical-kubernetes - 
> download.py:60 - Path is local filesystem, copying 
> /snap/conjure-up/987/spells/canonical-kubernetes to 
> /home/sjuarez/.cache/conjure-up/canonical-kubernetes
> 2018-04-26 16:41:18,868 [DEBUG] conjure-up/canonical-kubernetes - step.py:27 
> - steps: [ 00_process-providertype v: False c: []>,  Kubernetes 01_select-network v: True c: []>,  Distribution of Kubernetes 02_get-kubectl v: True c: []>,  Canonical Distribution of Kubernetes 03_cluster-info v: True c: []>, 
> ]
> 2018-04-26 16:41:22,892 [DEBUG] conjure-up/canonical-kubernetes - 
> telemetry.py:17 - Showing screen: Application Start
> 2018-04-26 16:41:22,899 [DEBUG] conjure-up/canonical-kubernetes - 
> telemetry.py:31 - OS: Linux-4.13.0-39-generic-x86_64-with-debian-stretch-sid
> 2018-04-26 16:41:23,336 [INFO] conjure-up/canonical-kubernetes - 
> events.py:172 - Watching for shutdown
> 2018-04-26 16:41:23,394 [DEBUG] conjure-up/canonical-kubernetes - 
> events.py:53 - Awaiting Shutdown at conjureup/events.py:175
> 2018-04-26 16:41:23,394 [DEBUG] conjure-up/canonical-kubernetes - 
> utils.py:512 - Pulling bundle for canonical-kubernetes from channel: stable
> 2018-04-26 16:41:25,739 [DEBUG] conjure-up/canonical-kubernetes - 
> events.py:53 - Awaiting Bootstrapped at 
> conjureup/controllers/bootstrap/tui.py:17
> 2018-04-26 16:41:27,334 [INFO] conjure-up/canonical-kubernetes - 
> juju.client.connection: connection.py:464 - Driver connected to juju 
> wss://54.157.235.156:17070/api
> 2018-04-26  16:41:28,020 [INFO] 
> conjure-up/canonical-kubernetes - common.py:74 - Connecting to Juju model 
> kube00...
> 2018-04-26 16:41:28,683 [INFO] conjure-up/canonical-kubernetes - 
> juju.client.connection: connection.py:464 - Driver connected to juju 
> wss://54.157.235.156:17070/model/9e1305ba-211c-4aa5-8dc8-b34986d682b1/api
> 2018-04-26 
> 
>  16:41:29,516 [DEBUG] conjure-up/canonical-kubernetes - events.py:53 - 
> Setting ModelConnected at conjureup/juju.py:174 in task run at 
> conjureup/controllers/bootstrap/common.py:19
> 2018-04-26 16:41:29,516 [INFO] conjure-up/canonical-kubernetes - common.py:74 
> - Juju model connected.
> 2018-04-26 16:41:29,520 [DEBUG] conjure-up/canonical-kubernetes - 
> events.py:53 - Setting Bootstrapped at 
> conjureup/controllers/bootstrap/common.py:42 in task run at 
> 

Re: We are pulling he 2.3.6 agents

[Nicholas Skaggs]

All 2.3.6 binaries should now be removed from distribution. The snap 
should refresh to 2.3.5 if you have the 2.3.6 binary.


Thanks,

Nicholas

On 04/23/2018 10:06 AM, Adam Israel wrote:

Hi all,

What wasn't clear to me from the email is that, with 2.3.6 pulled, 
we're unable to bootstrap new controllers without providing an 
alternate agent-stream, i.e., --agent-stream=proposed.


In future cases like this, is it feasible to roll back the snap to the 
previous version, so new installs work as expected?


On Sun, Apr 22, 2018 at 11:43 PM Tim Penhey > wrote:


Hey people,

We have field reports where a 2.3.6 upgrade interacted badly with some
charm settings causing Juju to get itself into a stuck, somewhat
corrupt
state. We are still evaluating how to fix this for stuck systems.

The symptom is the 2.3.6 upgrade fails and gets stuck.

The agents are being removed from streams to stop people accidentally
upgrading to a broken version, even though this breakage doesn't
impact
everyone.

We are also looking into the continuous integration tests around our
upgrades for extra testing to catch other issues like this one.

We will be releasing 2.3.7 shortly to address this isue.

Thanks for your patience.
Tim


-- 
Juju-dev mailing list

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

--
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: We are pulling he 2.3.6 agents

[Nicholas Skaggs]

All 2.3.6 binaries should now be removed from distribution. The snap 
should refresh to 2.3.5 if you have the 2.3.6 binary.


Thanks,

Nicholas

On 04/23/2018 10:06 AM, Adam Israel wrote:

Hi all,

What wasn't clear to me from the email is that, with 2.3.6 pulled, 
we're unable to bootstrap new controllers without providing an 
alternate agent-stream, i.e., --agent-stream=proposed.


In future cases like this, is it feasible to roll back the snap to the 
previous version, so new installs work as expected?


On Sun, Apr 22, 2018 at 11:43 PM Tim Penhey > wrote:


Hey people,

We have field reports where a 2.3.6 upgrade interacted badly with some
charm settings causing Juju to get itself into a stuck, somewhat
corrupt
state. We are still evaluating how to fix this for stuck systems.

The symptom is the 2.3.6 upgrade fails and gets stuck.

The agents are being removed from streams to stop people accidentally
upgrading to a broken version, even though this breakage doesn't
impact
everyone.

We are also looking into the continuous integration tests around our
upgrades for extra testing to catch other issues like this one.

We will be releasing 2.3.7 shortly to address this isue.

Thanks for your patience.
Tim


-- 
Juju-dev mailing list

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

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

Re: We are pulling he 2.3.6 agents

[Adam Israel]

Hi all,

What wasn't clear to me from the email is that, with 2.3.6 pulled, we're
unable to bootstrap new controllers without providing an alternate
agent-stream, i.e., --agent-stream=proposed.

In future cases like this, is it feasible to roll back the snap to the
previous version, so new installs work as expected?

On Sun, Apr 22, 2018 at 11:43 PM Tim Penhey 
wrote:

> Hey people,
>
> We have field reports where a 2.3.6 upgrade interacted badly with some
> charm settings causing Juju to get itself into a stuck, somewhat corrupt
> state. We are still evaluating how to fix this for stuck systems.
>
> The symptom is the 2.3.6 upgrade fails and gets stuck.
>
> The agents are being removed from streams to stop people accidentally
> upgrading to a broken version, even though this breakage doesn't impact
> everyone.
>
> We are also looking into the continuous integration tests around our
> upgrades for extra testing to catch other issues like this one.
>
> We will be releasing 2.3.7 shortly to address this isue.
>
> Thanks for your patience.
> Tim
>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
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: We are pulling he 2.3.6 agents

[Adam Israel]

Hi all,

What wasn't clear to me from the email is that, with 2.3.6 pulled, we're
unable to bootstrap new controllers without providing an alternate
agent-stream, i.e., --agent-stream=proposed.

In future cases like this, is it feasible to roll back the snap to the
previous version, so new installs work as expected?

On Sun, Apr 22, 2018 at 11:43 PM Tim Penhey 
wrote:

> Hey people,
>
> We have field reports where a 2.3.6 upgrade interacted badly with some
> charm settings causing Juju to get itself into a stuck, somewhat corrupt
> state. We are still evaluating how to fix this for stuck systems.
>
> The symptom is the 2.3.6 upgrade fails and gets stuck.
>
> The agents are being removed from streams to stop people accidentally
> upgrading to a broken version, even though this breakage doesn't impact
> everyone.
>
> We are also looking into the continuous integration tests around our
> upgrades for extra testing to catch other issues like this one.
>
> We will be releasing 2.3.7 shortly to address this isue.
>
> Thanks for your patience.
> Tim
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
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

Re:

[Cory Johns]

It looks like you're running up against
https://github.com/juju/python-libjuju/issues/216 for which there is a
pending fix at https://github.com/juju/python-libjuju/pull/217 which is
blocked because I couldn't figure out how to cover it in the test suite.
Please comment on that issue / PR and I will follow-up to either just make
a skipped test that can be manually run or come up with a way to include
it, and then get it released and conjure-up updated.

On Fri, Apr 20, 2018 at 5:03 PM, sSeBBaSs  wrote:

> Hi Cory,
>
> This how you can reproduce:
>
> juju bootstrap aws/us-east-1 juju-test-controller00 \
>   --config vpc-id=vpc- --config vpc-id-force=true \
>   --bootstrap-constraints "root-disk=128G mem=16G cores=4" \
>   --credential xx-xx-xx \
>   --auto-upgrade=false \
>   --bootstrap-series xenial
>
> juju change-user-password
>
> juju add-model kube00 us-east-1 --config vpc-id=vpc-
>
> conjure-up canonical-kubernetes aws juju-test-controller00 kube00
> [info] Summoning canonical-kubernetes to aws
> [error] no credentials provided
> [warning] Shutting down
>
> Here's the log file:
>
> 2018-04-20 17:59:58,870 [DEBUG] conjure-up/_unspecified_spell - juju.py:34
> - bin_path candidate found
> 2018-04-20 17:59:58,871 [DEBUG] conjure-up/_unspecified_spell - juju.py:34
> - wait_path candidate found
> 2018-04-20 17:59:58,984 [DEBUG] conjure-up/_unspecified_spell - app.py:279
> - Juju version: 2.3.6-xenial-amd64, conjure-up version: 2.5.6
> 2018-04-20 17:59:58,994 [DEBUG] conjure-up/_unspecified_spell - app.py:363
> - found spell {'key': 'canonical-kubernetes', 'name': 'Canonical
> Distribution of Kubernetes', 'description': 'Kubernetes is an open-source
> platform for deploying, scaling, and operations of application containers
> across a cluster of hosts. Kubernetes is portable in that it works with
> public, private, and hybrid clouds. Extensible through a pluggable
> infrastructure. Self healing in that it will automatically restart and
> place containers on healthy nodes if a node ever goes away.\n'}
> 2018-04-20 17:59:58,994 [DEBUG] conjure-up/_unspecified_spell -
> telemetry.py:31 - Spell Choice: canonical-kubernetes
> 2018-04-20 17:59:58,995 [DEBUG] conjure-up/canonical-kubernetes -
> download.py:60 - Path is local filesystem, copying
> /snap/conjure-up/994/spells/canonical-kubernetes to
> /home/sjuarez/.cache/conjure-up/canonical-kubernetes
> 2018-04-20 18:00:02,794 [DEBUG] conjure-up/canonical-kubernetes -
> step.py:27 - steps: [ 00_process-providertype v: False c: []>,  of Kubernetes 01_select-network v: True c: []>,  Distribution of Kubernetes 02_get-kubectl v: True c: []>,  Canonical Distribution of Kubernetes 03_cluster-info v: True c: []>,
>  []>]
> 2018-04-20 18:00:07,479 [DEBUG] conjure-up/canonical-kubernetes -
> telemetry.py:17 - Showing screen: Application Start
> 2018-04-20 18:00:07,490 [DEBUG] conjure-up/canonical-kubernetes -
> telemetry.py:31 - OS: Linux-4.13.0-38-generic-x86_
> 64-with-debian-stretch-sid
> 2018-04-20 18:00:07,882 [INFO] conjure-up/canonical-kubernetes -
> events.py:173 - Watching for shutdown
> 2018-04-20 18:00:07,921 [DEBUG] conjure-up/canonical-kubernetes -
> events.py:53 - Awaiting Shutdown at conjureup/events.py:176
> 2018-04-20 18:00:07,921 [DEBUG] conjure-up/canonical-kubernetes -
> utils.py:512 - Pulling bundle for canonical-kubernetes from channel: stable
> 2018-04-20 18:00:09,928 [DEBUG] conjure-up/canonical-kubernetes -
> events.py:53 - Awaiting Bootstrapped at conjureup/controllers/
> bootstrap/tui.py:17
> 2018-04-20 18:00:11,332 [INFO] conjure-up/canonical-kubernetes -
> juju.client.connection: connection.py:464 - Driver connected to juju wss://
> 35.172.211.159:17070/api
> 2018-04-20 18:00:11,664 [DEBUG] conjure-up/canonical-kubernetes -
> events.py:53 - Setting Error at conjureup/events.py:149
> 2018-04-20 18:00:11,668 [ERROR] conjure-up/canonical-kubernetes -
> events.py:161 - Unhandled exception in  coro= /snap/conjure-up/994/lib/python3.6/site-packages/conjureup/controllers/bootstrap/common.py:15>
> exception=JujuAPIError('no credentials provided',)>
> Traceback (most recent call last):
>   File "/snap/conjure-up/994/lib/python3.6/site-packages/
> conjureup/controllers/bootstrap/common.py", line 19, in run
> await self.do_add_model()
>   File "/snap/conjure-up/994/lib/python3.6/site-packages/
> conjureup/controllers/bootstrap/common.py", line 24, in do_add_model
> if await juju.model_available():
>   File "/snap/conjure-up/994/lib/python3.6/site-packages/conjureup/juju.py",
> line 153, in model_available
> await controller.connect(app.provider.controller)
>   File "/snap/conjure-up/994/lib/python3.6/site-packages/juju/controller.py",
> line 68, in connect
> await self._connector.connect_controller(controller_name)
>   File 
> "/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connector.py",
> line 90, in connect_controller
> 

Re:

[sSeBBaSs]

Hi Cory,

This how you can reproduce:

juju bootstrap aws/us-east-1 juju-test-controller00 \
  --config vpc-id=vpc- --config vpc-id-force=true \
  --bootstrap-constraints "root-disk=128G mem=16G cores=4" \
  --credential xx-xx-xx \
  --auto-upgrade=false \
  --bootstrap-series xenial

juju change-user-password

juju add-model kube00 us-east-1 --config vpc-id=vpc-

conjure-up canonical-kubernetes aws juju-test-controller00 kube00
[info] Summoning canonical-kubernetes to aws
[error] no credentials provided
[warning] Shutting down

Here's the log file:

2018-04-20 17:59:58,870 [DEBUG] conjure-up/_unspecified_spell - juju.py:34
- bin_path candidate found
2018-04-20 17:59:58,871 [DEBUG] conjure-up/_unspecified_spell - juju.py:34
- wait_path candidate found
2018-04-20 17:59:58,984 [DEBUG] conjure-up/_unspecified_spell - app.py:279
- Juju version: 2.3.6-xenial-amd64, conjure-up version: 2.5.6
2018-04-20 17:59:58,994 [DEBUG] conjure-up/_unspecified_spell - app.py:363
- found spell {'key': 'canonical-kubernetes', 'name': 'Canonical
Distribution of Kubernetes', 'description': 'Kubernetes is an open-source
platform for deploying, scaling, and operations of application containers
across a cluster of hosts. Kubernetes is portable in that it works with
public, private, and hybrid clouds. Extensible through a pluggable
infrastructure. Self healing in that it will automatically restart and
place containers on healthy nodes if a node ever goes away.\n'}
2018-04-20 17:59:58,994 [DEBUG] conjure-up/_unspecified_spell -
telemetry.py:31 - Spell Choice: canonical-kubernetes
2018-04-20 17:59:58,995 [DEBUG] conjure-up/canonical-kubernetes -
download.py:60 - Path is local filesystem, copying
/snap/conjure-up/994/spells/canonical-kubernetes to
/home/sjuarez/.cache/conjure-up/canonical-kubernetes
2018-04-20 18:00:02,794 [DEBUG] conjure-up/canonical-kubernetes -
step.py:27 - steps: [, , , ,
]
2018-04-20 18:00:07,479 [DEBUG] conjure-up/canonical-kubernetes -
telemetry.py:17 - Showing screen: Application Start
2018-04-20 18:00:07,490 [DEBUG] conjure-up/canonical-kubernetes -
telemetry.py:31 - OS: Linux-4.13.0-38-generic-x86_64-with-debian-stretch-sid
2018-04-20 18:00:07,882 [INFO] conjure-up/canonical-kubernetes -
events.py:173 - Watching for shutdown
2018-04-20 18:00:07,921 [DEBUG] conjure-up/canonical-kubernetes -
events.py:53 - Awaiting Shutdown at conjureup/events.py:176
2018-04-20 18:00:07,921 [DEBUG] conjure-up/canonical-kubernetes -
utils.py:512 - Pulling bundle for canonical-kubernetes from channel: stable
2018-04-20 18:00:09,928 [DEBUG] conjure-up/canonical-kubernetes -
events.py:53 - Awaiting Bootstrapped at
conjureup/controllers/bootstrap/tui.py:17
2018-04-20 18:00:11,332 [INFO] conjure-up/canonical-kubernetes -
juju.client.connection: connection.py:464 - Driver connected to juju wss://
35.172.211.159:17070/api
2018-04-20 18:00:11,664 [DEBUG] conjure-up/canonical-kubernetes -
events.py:53 - Setting Error at conjureup/events.py:149
2018-04-20 18:00:11,668 [ERROR] conjure-up/canonical-kubernetes -
events.py:161 - Unhandled exception in 
exception=JujuAPIError('no credentials provided',)>
Traceback (most recent call last):
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/conjureup/controllers/bootstrap/common.py",
line 19, in run
await self.do_add_model()
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/conjureup/controllers/bootstrap/common.py",
line 24, in do_add_model
if await juju.model_available():
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/conjureup/juju.py", line
153, in model_available
await controller.connect(app.provider.controller)
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/juju/controller.py", line
68, in connect
await self._connector.connect_controller(controller_name)
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connector.py",
line 90, in connect_controller
bakery_client=self.bakery_client_for_controller(controller_name),
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connector.py",
line 59, in connect
self._connection = await Connection.connect(**kwargs)
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connection.py",
line 166, in connect
await self._connect_with_redirect([(endpoint, cacert)])
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connection.py",
line 509, in _connect_with_redirect
login_result = await self._connect_with_login(endpoints)
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connection.py",
line 481, in _connect_with_login
result = (await self.login())['response']
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connection.py",
line 536, in login
"params": params,
  File
"/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connection.py",
line 314, in rpc
raise errors.JujuAPIError(result)
juju.errors.JujuAPIError: no credentials provided
2018-04-20 18:00:11,696 

Re:

[Cory Johns]

Sebastian,

Can you provide us with the conjure-up.log file from
~/.cache/conjure-up/conjure-up.log?  Are you selecting a credential name
from the list in conjure-up and then getting that error, or is the error
coming from later in the process (after starting the deployment)?

I don't think that the non-admin user should make any difference, as long
as you can authenticate to the controller as that user with Juju, but I
haven't actually tested with a non-standard user.  But the error sounds
like it's coming from something else anyway, and as I said, I wouldn't
expect it to make much difference.

- Cory

On Fri, Apr 20, 2018 at 2:29 PM, sSeBBaSs  wrote:

> Hi guys
>
> I need some help.
> I'm trying to conjure-up canonical-kubernetes, in an already bootstrapped
> controller on an custom model, with another user than the default admin,
> and I keep receiving a credentials not found error message.
>
>
>
>
>
> --
> ---
> Sebastian Juárez
> Mail: ssebb...@gmail.com
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Should 'juju status' always include a timestamp

[Cory Johns]

I'm also +1 on a timestamp.

On Wed, Apr 18, 2018 at 8:22 AM, Jason Hobbs 
wrote:

> Yes, a timestamp is always appropriate.
>
> On Wed, Apr 18, 2018 at 3:12 AM, Merlijn Sebrechts
>  wrote:
> > +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
> >
>
> --
> 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: Should 'juju status' always include a timestamp

[Jason Hobbs]

Yes, a timestamp is always appropriate.

On Wed, Apr 18, 2018 at 3:12 AM, Merlijn Sebrechts
 wrote:
> +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
>

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

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

Re: Cinder-Ceph Multi-Backend Example

[James Beedy]

Alex,

Thanks for the response, and nice work on the write up.

~James

On Mon, Apr 16, 2018 at 5:28 AM, alex barchiesi 
wrote:

> Hi James,
> at GARR we recently tested the cinder multi backend with the following
> idea in mind:
> support 3 different backends:
>
>- a default one, for general-purpose disks like virtual machine boot
>disks: replicated pool with replica factor equal to 3
>- a reduced redundancy one: replicated pool with replica factor 2,
>which should slightly improve latency
>- a large capacity one: erasure-coded (possibly with a small frontend
>replicated pool)
>
> Premise: we have a juju deployed O~S (spanning 3 geographical data
> centers).
>
> We configured Cinder such that it allows selection between multiple
> “Volume Types”, where each Volume Type points to a distinct Ceph pool
> within the same Ceph cluster.
>
> This is the simplest configuration, as it involves Cinder configuration
> alone. Volumes which are created can be later attached to running
> instances, but all instances will have their boot disk on the default pool
> cinder-ceph.
>
> We faced some issues as reported in details here: https://docs.google.com/
> document/d/1VSS28cvZBIOEzTOmVMWZ0o9FiVFkVLvu__ZOLxneMqQ/edit#
>
> Would be interesting to find a way to be able to select the pool also for
> the boot disk of a VM
>
> Any comment, idea, "whatever" (also on the doc) is very much appreciated
>
> best Alex
>
>
>
> Dr. Alex Barchiesi
> 
> Senior cloud architect
> Art -Science relationships responsible
>
> GARR CSD department
>
> Rome GARR: +39 06 4962 2302
> Lausanne EPFL: +41 (0) 774215266
>
> linkedin: alex barchiesi
> 
> _
> I started with nothing and I still have most of it.
>
>
>
> On Sat, Apr 14, 2018 at 3:25 AM, James Beedy  wrote:
>
>> Looking for examples that describe how to consume multiple ceph backends
>> using the cinder-ceph charm.
>>
>> Thanks
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: bridge activation error: yaml: unmarshal errors:, line 7: field bonds not found in struct netplan

[Vidmantas Rinkevičius]

Submitted

https://bugs.launchpad.net/juju/+bug/1764735


On 2018-04-17 15:29, John Meinel wrote:
btw, including a copy of your /etc/netplan/*.yaml files once you've 
bootstrapped would probably be useful to make sure we're addressing 
the issues that you're seeing.


John
=:->


On Tue, Apr 17, 2018 at 4:18 PM, John Meinel > wrote:


We should get a bug following this. But essentially Bionic changed
how networking configuration is being done, from
/etc/network/interfaces to /etc/netplan/*.yaml files.

When we started implementing support for netplan, they hadn't
finished support for bonds, so we didn't implement support for
reading bonds and configuring them.

They have since finished supporting bonds in netplan, and we need
to update our support for netplan to include bonds.

While we *could* just not past "strict" to the yaml library, I
think the net result of that would not be positive, because we
might try to create configurations not being aware of part of your
network.


On Tue, Apr 17, 2018 at 10:46 AM, Vidmantas Rinkevičius
> wrote:

Hi,

During openstack deployment juju gives error on all lxd
containers.

Example:

sudo juju status

3/lxd/0  down pending  bionic bridge
activation error: yaml: unmarshal errors:
  line 7: field bonds not found in struct netplan.

yaml:

openstack-dashboard:
    annotations:
  gui-x: '500'
  gui-y: '-250'
    charm: cs:~openstack-charmers-next/bionic/openstack-dashboard
    num_units: 1
    bindings:
  website: web
    options:
  openstack-origin: distro-proposed
    to:
    - lxd:3


I am deploying 18.04 and I use network spaces.

Any ideas why this error occurs?






-- 
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: bridge activation error: yaml: unmarshal errors:, line 7: field bonds not found in struct netplan

[John Meinel]

btw, including a copy of your /etc/netplan/*.yaml files once you've
bootstrapped would probably be useful to make sure we're addressing the
issues that you're seeing.

John
=:->


On Tue, Apr 17, 2018 at 4:18 PM, John Meinel  wrote:

> We should get a bug following this. But essentially Bionic changed how
> networking configuration is being done, from /etc/network/interfaces to
> /etc/netplan/*.yaml files.
>
> When we started implementing support for netplan, they hadn't finished
> support for bonds, so we didn't implement support for reading bonds and
> configuring them.
>
> They have since finished supporting bonds in netplan, and we need to
> update our support for netplan to include bonds.
>
> While we *could* just not past "strict" to the yaml library, I think the
> net result of that would not be positive, because we might try to create
> configurations not being aware of part of your network.
>
>
> On Tue, Apr 17, 2018 at 10:46 AM, Vidmantas Rinkevičius <
> vidmantas.rinkevic...@vgtu.lt> wrote:
>
>> Hi,
>>
>> During openstack deployment juju gives error on all lxd containers.
>>
>> Example:
>>
>> sudo juju status
>>
>> 3/lxd/0  down pending  bionic bridge activation
>> error: yaml: unmarshal errors:
>>   line 7: field bonds not found in struct netplan.
>>
>> yaml:
>>
>> openstack-dashboard:
>> annotations:
>>   gui-x: '500'
>>   gui-y: '-250'
>> charm: cs:~openstack-charmers-next/bionic/openstack-dashboard
>> num_units: 1
>> bindings:
>>   website: web
>> options:
>>   openstack-origin: distro-proposed
>> to:
>> - lxd:3
>>
>>
>> I am deploying 18.04 and I use network spaces.
>>
>> Any ideas why this error occurs?
>>
>>
>>
>>
>>
>>
>> --
>> 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: bridge activation error: yaml: unmarshal errors:, line 7: field bonds not found in struct netplan

[John Meinel]

We should get a bug following this. But essentially Bionic changed how
networking configuration is being done, from /etc/network/interfaces to
/etc/netplan/*.yaml files.

When we started implementing support for netplan, they hadn't finished
support for bonds, so we didn't implement support for reading bonds and
configuring them.

They have since finished supporting bonds in netplan, and we need to update
our support for netplan to include bonds.

While we *could* just not past "strict" to the yaml library, I think the
net result of that would not be positive, because we might try to create
configurations not being aware of part of your network.


On Tue, Apr 17, 2018 at 10:46 AM, Vidmantas Rinkevičius <
vidmantas.rinkevic...@vgtu.lt> wrote:

> Hi,
>
> During openstack deployment juju gives error on all lxd containers.
>
> Example:
>
> sudo juju status
>
> 3/lxd/0  down pending  bionic bridge activation error:
> yaml: unmarshal errors:
>   line 7: field bonds not found in struct netplan.
>
> yaml:
>
> openstack-dashboard:
> annotations:
>   gui-x: '500'
>   gui-y: '-250'
> charm: cs:~openstack-charmers-next/bionic/openstack-dashboard
> num_units: 1
> bindings:
>   website: web
> options:
>   openstack-origin: distro-proposed
> to:
> - lxd:3
>
>
> I am deploying 18.04 and I use network spaces.
>
> Any ideas why this error occurs?
>
>
>
>
>
>
> --
> 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: Cinder-Ceph Multi-Backend Example

[alex barchiesi]

Hi James,
at GARR we recently tested the cinder multi backend with the following idea
in mind:
support 3 different backends:

   - a default one, for general-purpose disks like virtual machine boot
   disks: replicated pool with replica factor equal to 3
   - a reduced redundancy one: replicated pool with replica factor 2, which
   should slightly improve latency
   - a large capacity one: erasure-coded (possibly with a small frontend
   replicated pool)

Premise: we have a juju deployed O~S (spanning 3 geographical data centers).

We configured Cinder such that it allows selection between multiple “Volume
Types”, where each Volume Type points to a distinct Ceph pool within the
same Ceph cluster.

This is the simplest configuration, as it involves Cinder configuration
alone. Volumes which are created can be later attached to running
instances, but all instances will have their boot disk on the default pool
cinder-ceph.

We faced some issues as reported in details here:
https://docs.google.com/document/d/1VSS28cvZBIOEzTOmVMWZ0o9FiVFkVLvu__ZOLxneMqQ/edit#

Would be interesting to find a way to be able to select the pool also for
the boot disk of a VM

Any comment, idea, "whatever" (also on the doc) is very much appreciated

best Alex



Dr. Alex Barchiesi

Senior cloud architect
Art -Science relationships responsible

GARR CSD department

Rome GARR: +39 06 4962 2302
Lausanne EPFL: +41 (0) 774215266

linkedin: alex barchiesi

_
I started with nothing and I still have most of it.



On Sat, Apr 14, 2018 at 3:25 AM, James Beedy  wrote:

> Looking for examples that describe how to consume multiple ceph backends
> using the cinder-ceph charm.
>
> 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: Implement aws style user-data

[Drew Wells]

Thanks John, I'll take a look. My hacky solution of just creating an
interface for that IP on the host is working so far.

On Wed, Apr 11, 2018 at 11:47 PM John Meinel  wrote:

> I think the actual question is how to create a service that responds to
> metadata requests. In that case, it is a bit hard to say from the outside,
> because it is very dependent on what software-defined-networking you're
> using.
>
> 169.254.169.254 is a link-local address, which means it can't be routed
> across the network. So you have to have your SDN know where to send your
> packets (it effectively looks like the switch is the thing running the
> metadata server, because that's the only thing on the other side of a
> link-local connection).
>
> I don't have any specific information about how it is done on the various
> clouds. Though you could look at openstack which also implements a
> metadata-server and is open source code.
>
> John
> =:->
>
>
> On Wed, Apr 11, 2018 at 7:58 PM, Heather Lanigan <
> heather.lani...@canonical.com> wrote:
>
>> Hi Drew,
>>
>> Juju uses cloud-init currently when provisioning machines today.  We've
>> recently added a bootstrap configuration option to allow for cloud-init
>> yaml to
>> be passed through.
>>
>> Details can be found in an old bug:
>> https://bugs.launchpad.net/juju/+bug/1535891
>>
>> I need to get this added to the docs.  There is a known issue using lists
>> in the yaml file, but strings work fine.
>>
>> -Heather
>>
>> On Wed, Mar 28, 2018 at 4:16 PM, Drew Wells 
>> wrote:
>>
>>> I want to implement an aws user-data like interface. So the Ubuntu host
>>> would respond on 169.254.169.254 and this address would be routable by
>>> every juju managed machine and the containers running on those machines.
>>>
>>> Where would I get started for setting something like this up?
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Implement aws style user-data

[John Meinel]

I think the actual question is how to create a service that responds to
metadata requests. In that case, it is a bit hard to say from the outside,
because it is very dependent on what software-defined-networking you're
using.

169.254.169.254 is a link-local address, which means it can't be routed
across the network. So you have to have your SDN know where to send your
packets (it effectively looks like the switch is the thing running the
metadata server, because that's the only thing on the other side of a
link-local connection).

I don't have any specific information about how it is done on the various
clouds. Though you could look at openstack which also implements a
metadata-server and is open source code.

John
=:->


On Wed, Apr 11, 2018 at 7:58 PM, Heather Lanigan <
heather.lani...@canonical.com> wrote:

> Hi Drew,
>
> Juju uses cloud-init currently when provisioning machines today.  We've
> recently added a bootstrap configuration option to allow for cloud-init
> yaml to
> be passed through.
>
> Details can be found in an old bug: https://bugs.launchpad.
> net/juju/+bug/1535891
>
> I need to get this added to the docs.  There is a known issue using lists
> in the yaml file, but strings work fine.
>
> -Heather
>
> On Wed, Mar 28, 2018 at 4:16 PM, Drew Wells 
> wrote:
>
>> I want to implement an aws user-data like interface. So the Ubuntu host
>> would respond on 169.254.169.254 and this address would be routable by
>> every juju managed machine and the containers running on those machines.
>>
>> Where would I get started for setting something like this up?
>>
>> --
>> 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: Implement aws style user-data

[Heather Lanigan]

Hi Drew,

Juju uses cloud-init currently when provisioning machines today.  We've
recently added a bootstrap configuration option to allow for cloud-init
yaml to
be passed through.

Details can be found in an old bug:
https://bugs.launchpad.net/juju/+bug/1535891

I need to get this added to the docs.  There is a known issue using lists
in the yaml file, but strings work fine.

-Heather

On Wed, Mar 28, 2018 at 4:16 PM, Drew Wells  wrote:

> I want to implement an aws user-data like interface. So the Ubuntu host
> would respond on 169.254.169.254 and this address would be routable by
> every juju managed machine and the containers running on those machines.
>
> Where would I get started for setting something like this up?
>
> --
> 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: Openstack User Feedback

[Ryan Beisner]

Touched base on IRC out of band with this, just circling back here as well
to confirm that we're working to reproduce and advise.

Thanks again,

Ryan

On Wed, Apr 4, 2018 at 11:04 AM, James Beedy  wrote:

> forgot one: https://bugs.launchpad.net/charms.ceph/+bug/1761230
>
> On Wed, Apr 4, 2018 at 8:19 AM, James Beedy  wrote:
>
>> Here are the bugs:
>>
>> 1) https://bugs.launchpad.net/charms.ceph/+bug/1761214
>> 2) https://bugs.launchpad.net/charms.ceph/+bug/1761208
>> 3) https://bugs.launchpad.net/charm-ceph-fs/+bug/1753640
>>
>>
>> On Wed, Apr 4, 2018 at 5:52 AM, James Beedy  wrote:
>>
>>> Hello,
>>>
>>> @chrismacnaughton @jamespage @beisner @openstack-charmers ceph <->
>>> openstack such a broken bone right now.
>>>
>>> Please fix.
>>>
>>> Here is my bundle https://pastebin.com/gEUYaiFh
>>>
>>>
>>> (From IRC)
>>> 05:29  heres my deploy, looks great
>>> 05:29  https://pastebin.com/a2iNrBxv
>>> 
>>> jamesbeedy - Pastebin.com
>>> 
>>> 05:30  following a (what appears to be successful) deploy, I only
>>> see a 'glance' pool in ceph, and its in warning due to pg_num > pgp_num
>>> 05:31  increasing pgp_num gets me a healthy status
>>> 05:32  follow by another health warning
>>> https://paste.ubuntu.com/p/zD7HxMz6s6/
>>> Ubuntu Pastebin
>>> 
>>> 05:32  running `sudo ceph osd pool application enable glance rbd`
>>> got me back to healthy on my 'glance' pool
>>> 05:33  these are the two first papercuts
>>> 05:33  next - Manager for service cinder-volume cinder@cinder-ceph
>>> is reporting problems, not sending heartbeat. Service will appear "down".
>>> 05:34   the only pool I see following a deploy is 'glance'
>>> https://paste.ubuntu.com/p/Gg5G3Bmhq3/
>>> Ubuntu Pastebin
>>> 
>>> 05:36  when I try to create an instance in openstack I get the
>>> good ol' - Error: Failed to perform requested operation on instance "aset",
>>> the instance has an error status: Please try again later [Error: Build of
>>> instance 13e170cd-6aea-43ed-9ca1-de2ae62c3118 aborted: Volume
>>> 72e36907-81df-446c-b580-78bd96134ce0 did not finish being created even
>>> after we waited 0 seconds or 1 attempts. And its status is error.].
>>> 05:36  possibly there is a bunch of post deploy configuration that
>>> need be done here?
>>>
>>>
>>> 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: More juju upgrade-juju failings

[Sandor Zeestraten]

Glad to help. I reported http://pad.lv/1761288 regarding the ability to
abort/rollback broken upgrades in order to get out of sticky upgrade
situations.
Also hope to see a clean up of the UX and the addition of actual dry-run
capabilities in http://pad.lv/1638714

We're looking forward to upgrading from 2.3 to 2.4 with ease and confidence!

Regards
--
Sandor Zeestraten

On Wed, Apr 4, 2018 at 8:13 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Sandor, thanks for this perspective! It was really helpful to see how
> upgrades went for you in real life, and more importantly, that 2.3.x seems
> to have gone smoothly. We'll be carefully watching and monitoring 2.3->2.4
> upgrades as the release draws nearer.
>
> Nicholas
>
> On 04/01/2018 04:04 AM, Sandor Zeestraten wrote:
>
>> Hi Nicholas,
>>
>> Thanks for the input. I wrote up a short blog post about our experiences
>> going from 2.1 to 2.3. Hopefully it provides some feedback and can be
>> helpful for others in the same position.
>>
>> http://zeestrataca.com/posts/upgrading-juju/ <
>> http://zeestrataca.com/posts/upgrading-juju/>
>>
>> Regards
>> --
>> Sandor Zeestraten
>>
>>
>> On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs <
>> nicholas.ska...@canonical.com >
>> wrote:
>>
>> Sandor, re:sharing experiences, if you want to frame some
>> scenarios you've had trouble with, please feel free to share
>> those. Distilling it down into a repeatable deployment -> upgrade
>> will help us understand and account for it. As Tim mentioned,
>> tools like juju-upgrader are generally candidates for
>> incorporation into juju itself, provided they prove valuable to
>> the community at large. We always welcome any PR's, but especially
>> so for improvements that add this functionality.
>>
>> Nicholas
>>
>> On 03/21/2018 08:43 PM, Tim Penhey wrote:
>>
>> Hi Sandor,
>>
>> Streamlining upgrades is definitely on the team's road-map. We
>> are aware
>> of the juju-upgrader plugin, and will be looking to
>> incorporate some of
>> that functionality into the core codebase.
>>
>> The core team has worked on better upgrade testing as part of
>> our CI,
>> which enables more test scenarios to help discover issues
>> between more
>> versions.
>>
>> Cheers,
>> Tim
>>
>> On 22/03/18 05:32, Sandor Zeestraten wrote:
>>
>> Is this shared google doc open for external contributors?
>>
>> After spending a while upgrading our 2.1.x environments to
>> 2.3.x and
>> hitting some bugs along the way in staging (see below),
>> I'd agree that
>> the process needs a bit of love and wouldn't mind sharing
>> some experiences.
>>
>> Rick mentioned https://launchpad.net/juju-upgrader
>>  on the Juju show a
>> couple of episodes back, but I haven't seen it mentioned
>> anywhere else
>> yet. Are those tools supposed to deal with some of these
>> issues and
>> eventually be rolled into juju-core?
>>
>> https://bugs.launchpad.net/juju/+bug/1746265
>> 
>> https://bugs.launchpad.net/juju/+bug/1748294
>> 
>> https://bugs.launchpad.net/juju/+bug/1697936
>> 
>>
>> Regards
>> --
>> Sandor Zeestraten
>>
>> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth
>> 
>> >> wrote:
>>
>>
>>  I think this UX on the upgrade process has obvious
>> problems. Nobody
>>  should have to guess at what to do, in which sequence.
>>
>>  Can I suggest that we have a shared Google doc to
>> mock up a nice
>>  experience starting with the simple command 'juju
>> upgrade' which then
>>  walks people through the process, including the
>> distinction between
>>  upgrading charms, agents and controllers, as well as
>> the ability to do
>>  aerospace-grade upgrades through live migration to
>> newer controllers?
>>
>>  Mark
>>
>>  On 02/27/2018 11:26 PM, Tim Penhey wrote:
>>  > Hi Daniel,
>>  >
>>  > The issue here is that you are upgrading the
>> default model, not the
>>  > controller model itself.
>>  >
>>  > I think we could make the error messaging more

Re: More juju upgrade-juju failings

[Sandor Zeestraten]

Glad to help. I reported http://pad.lv/1761288 regarding the ability to
abort/rollback broken upgrades in order to get out of sticky upgrade
situations.
Also hope to see a clean up of the UX and the addition of actual dry-run
capabilities in http://pad.lv/1638714

We're looking forward to upgrading from 2.3 to 2.4 with ease and confidence!

Regards
--
Sandor Zeestraten

On Wed, Apr 4, 2018 at 8:13 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Sandor, thanks for this perspective! It was really helpful to see how
> upgrades went for you in real life, and more importantly, that 2.3.x seems
> to have gone smoothly. We'll be carefully watching and monitoring 2.3->2.4
> upgrades as the release draws nearer.
>
> Nicholas
>
> On 04/01/2018 04:04 AM, Sandor Zeestraten wrote:
>
>> Hi Nicholas,
>>
>> Thanks for the input. I wrote up a short blog post about our experiences
>> going from 2.1 to 2.3. Hopefully it provides some feedback and can be
>> helpful for others in the same position.
>>
>> http://zeestrataca.com/posts/upgrading-juju/ <
>> http://zeestrataca.com/posts/upgrading-juju/>
>>
>> Regards
>> --
>> Sandor Zeestraten
>>
>>
>> On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs <
>> nicholas.ska...@canonical.com >
>> wrote:
>>
>> Sandor, re:sharing experiences, if you want to frame some
>> scenarios you've had trouble with, please feel free to share
>> those. Distilling it down into a repeatable deployment -> upgrade
>> will help us understand and account for it. As Tim mentioned,
>> tools like juju-upgrader are generally candidates for
>> incorporation into juju itself, provided they prove valuable to
>> the community at large. We always welcome any PR's, but especially
>> so for improvements that add this functionality.
>>
>> Nicholas
>>
>> On 03/21/2018 08:43 PM, Tim Penhey wrote:
>>
>> Hi Sandor,
>>
>> Streamlining upgrades is definitely on the team's road-map. We
>> are aware
>> of the juju-upgrader plugin, and will be looking to
>> incorporate some of
>> that functionality into the core codebase.
>>
>> The core team has worked on better upgrade testing as part of
>> our CI,
>> which enables more test scenarios to help discover issues
>> between more
>> versions.
>>
>> Cheers,
>> Tim
>>
>> On 22/03/18 05:32, Sandor Zeestraten wrote:
>>
>> Is this shared google doc open for external contributors?
>>
>> After spending a while upgrading our 2.1.x environments to
>> 2.3.x and
>> hitting some bugs along the way in staging (see below),
>> I'd agree that
>> the process needs a bit of love and wouldn't mind sharing
>> some experiences.
>>
>> Rick mentioned https://launchpad.net/juju-upgrader
>>  on the Juju show a
>> couple of episodes back, but I haven't seen it mentioned
>> anywhere else
>> yet. Are those tools supposed to deal with some of these
>> issues and
>> eventually be rolled into juju-core?
>>
>> https://bugs.launchpad.net/juju/+bug/1746265
>> 
>> https://bugs.launchpad.net/juju/+bug/1748294
>> 
>> https://bugs.launchpad.net/juju/+bug/1697936
>> 
>>
>> Regards
>> --
>> Sandor Zeestraten
>>
>> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth
>> 
>> >> wrote:
>>
>>
>>  I think this UX on the upgrade process has obvious
>> problems. Nobody
>>  should have to guess at what to do, in which sequence.
>>
>>  Can I suggest that we have a shared Google doc to
>> mock up a nice
>>  experience starting with the simple command 'juju
>> upgrade' which then
>>  walks people through the process, including the
>> distinction between
>>  upgrading charms, agents and controllers, as well as
>> the ability to do
>>  aerospace-grade upgrades through live migration to
>> newer controllers?
>>
>>  Mark
>>
>>  On 02/27/2018 11:26 PM, Tim Penhey wrote:
>>  > Hi Daniel,
>>  >
>>  > The issue here is that you are upgrading the
>> default model, not the
>>  > controller model itself.
>>  >
>>  > I think we could make the error messaging more

Re: More juju upgrade-juju failings

[Nicholas Skaggs]

Sandor, thanks for this perspective! It was really helpful to see how 
upgrades went for you in real life, and more importantly, that 2.3.x 
seems to have gone smoothly. We'll be carefully watching and monitoring 
2.3->2.4 upgrades as the release draws nearer.


Nicholas

On 04/01/2018 04:04 AM, Sandor Zeestraten wrote:

Hi Nicholas,

Thanks for the input. I wrote up a short blog post about our 
experiences going from 2.1 to 2.3. Hopefully it provides some feedback 
and can be helpful for others in the same position.


http://zeestrataca.com/posts/upgrading-juju/ 



Regards
--
Sandor Zeestraten

On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs 
> 
wrote:


Sandor, re:sharing experiences, if you want to frame some
scenarios you've had trouble with, please feel free to share
those. Distilling it down into a repeatable deployment -> upgrade
will help us understand and account for it. As Tim mentioned,
tools like juju-upgrader are generally candidates for
incorporation into juju itself, provided they prove valuable to
the community at large. We always welcome any PR's, but especially
so for improvements that add this functionality.

Nicholas

On 03/21/2018 08:43 PM, Tim Penhey wrote:

Hi Sandor,

Streamlining upgrades is definitely on the team's road-map. We
are aware
of the juju-upgrader plugin, and will be looking to
incorporate some of
that functionality into the core codebase.

The core team has worked on better upgrade testing as part of
our CI,
which enables more test scenarios to help discover issues
between more
versions.

Cheers,
Tim

On 22/03/18 05:32, Sandor Zeestraten wrote:

Is this shared google doc open for external contributors?

After spending a while upgrading our 2.1.x environments to
2.3.x and
hitting some bugs along the way in staging (see below),
I'd agree that
the process needs a bit of love and wouldn't mind sharing
some experiences.

Rick mentioned https://launchpad.net/juju-upgrader
 on the Juju show a
couple of episodes back, but I haven't seen it mentioned
anywhere else
yet. Are those tools supposed to deal with some of these
issues and
eventually be rolled into juju-core?

https://bugs.launchpad.net/juju/+bug/1746265

https://bugs.launchpad.net/juju/+bug/1748294

https://bugs.launchpad.net/juju/+bug/1697936


Regards
--
Sandor Zeestraten

On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth

>> wrote:


     I think this UX on the upgrade process has obvious
problems. Nobody
     should have to guess at what to do, in which sequence.

     Can I suggest that we have a shared Google doc to
mock up a nice
     experience starting with the simple command 'juju
upgrade' which then
     walks people through the process, including the
distinction between
     upgrading charms, agents and controllers, as well as
the ability to do
     aerospace-grade upgrades through live migration to
newer controllers?

     Mark

     On 02/27/2018 11:26 PM, Tim Penhey wrote:
     > Hi Daniel,
     >
     > The issue here is that you are upgrading the
default model, not the
     > controller model itself.
     >
     > I think we could make the error messaging more
clear, and also
     have the
     > command also check the controller version before
showing a lot of
     > baffling output.
     >
     > What you need to do is upgrade the controller model
first, so either
     > switch to it or run:
     >
     >   juju upgrade-juju -m controller --agent-version 2.3.3
     >
     > Cheers,
     > Tim
     >
     > On 28/02/18 11:19, Daniel Bidwell wrote:
     >> I am running on juju 2.3.3-xenial-amd64 and my
controllers are
     running
     >> in VMware Vsphere with version 2.3.2.  

Re: More juju upgrade-juju failings

[Nicholas Skaggs]

Sandor, thanks for this perspective! It was really helpful to see how 
upgrades went for you in real life, and more importantly, that 2.3.x 
seems to have gone smoothly. We'll be carefully watching and monitoring 
2.3->2.4 upgrades as the release draws nearer.


Nicholas

On 04/01/2018 04:04 AM, Sandor Zeestraten wrote:

Hi Nicholas,

Thanks for the input. I wrote up a short blog post about our 
experiences going from 2.1 to 2.3. Hopefully it provides some feedback 
and can be helpful for others in the same position.


http://zeestrataca.com/posts/upgrading-juju/ 



Regards
--
Sandor Zeestraten

On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs 
> 
wrote:


Sandor, re:sharing experiences, if you want to frame some
scenarios you've had trouble with, please feel free to share
those. Distilling it down into a repeatable deployment -> upgrade
will help us understand and account for it. As Tim mentioned,
tools like juju-upgrader are generally candidates for
incorporation into juju itself, provided they prove valuable to
the community at large. We always welcome any PR's, but especially
so for improvements that add this functionality.

Nicholas

On 03/21/2018 08:43 PM, Tim Penhey wrote:

Hi Sandor,

Streamlining upgrades is definitely on the team's road-map. We
are aware
of the juju-upgrader plugin, and will be looking to
incorporate some of
that functionality into the core codebase.

The core team has worked on better upgrade testing as part of
our CI,
which enables more test scenarios to help discover issues
between more
versions.

Cheers,
Tim

On 22/03/18 05:32, Sandor Zeestraten wrote:

Is this shared google doc open for external contributors?

After spending a while upgrading our 2.1.x environments to
2.3.x and
hitting some bugs along the way in staging (see below),
I'd agree that
the process needs a bit of love and wouldn't mind sharing
some experiences.

Rick mentioned https://launchpad.net/juju-upgrader
 on the Juju show a
couple of episodes back, but I haven't seen it mentioned
anywhere else
yet. Are those tools supposed to deal with some of these
issues and
eventually be rolled into juju-core?

https://bugs.launchpad.net/juju/+bug/1746265

https://bugs.launchpad.net/juju/+bug/1748294

https://bugs.launchpad.net/juju/+bug/1697936


Regards
--
Sandor Zeestraten

On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth

>> wrote:


     I think this UX on the upgrade process has obvious
problems. Nobody
     should have to guess at what to do, in which sequence.

     Can I suggest that we have a shared Google doc to
mock up a nice
     experience starting with the simple command 'juju
upgrade' which then
     walks people through the process, including the
distinction between
     upgrading charms, agents and controllers, as well as
the ability to do
     aerospace-grade upgrades through live migration to
newer controllers?

     Mark

     On 02/27/2018 11:26 PM, Tim Penhey wrote:
     > Hi Daniel,
     >
     > The issue here is that you are upgrading the
default model, not the
     > controller model itself.
     >
     > I think we could make the error messaging more
clear, and also
     have the
     > command also check the controller version before
showing a lot of
     > baffling output.
     >
     > What you need to do is upgrade the controller model
first, so either
     > switch to it or run:
     >
     >   juju upgrade-juju -m controller --agent-version 2.3.3
     >
     > Cheers,
     > Tim
     >
     > On 28/02/18 11:19, Daniel Bidwell wrote:
     >> I am running on juju 2.3.3-xenial-amd64 and my
controllers are
     running
     >> in VMware Vsphere with version 2.3.2.  

Re: Openstack User Feedback

[James Beedy]

forgot one: https://bugs.launchpad.net/charms.ceph/+bug/1761230

On Wed, Apr 4, 2018 at 8:19 AM, James Beedy  wrote:

> Here are the bugs:
>
> 1) https://bugs.launchpad.net/charms.ceph/+bug/1761214
> 2) https://bugs.launchpad.net/charms.ceph/+bug/1761208
> 3) https://bugs.launchpad.net/charm-ceph-fs/+bug/1753640
>
>
> On Wed, Apr 4, 2018 at 5:52 AM, James Beedy  wrote:
>
>> Hello,
>>
>> @chrismacnaughton @jamespage @beisner @openstack-charmers ceph <->
>> openstack such a broken bone right now.
>>
>> Please fix.
>>
>> Here is my bundle https://pastebin.com/gEUYaiFh
>>
>>
>> (From IRC)
>> 05:29  heres my deploy, looks great
>> 05:29  https://pastebin.com/a2iNrBxv
>> 
>> jamesbeedy - Pastebin.com
>> 
>> 05:30  following a (what appears to be successful) deploy, I only
>> see a 'glance' pool in ceph, and its in warning due to pg_num > pgp_num
>> 05:31  increasing pgp_num gets me a healthy status
>> 05:32  follow by another health warning
>> https://paste.ubuntu.com/p/zD7HxMz6s6/
>> Ubuntu Pastebin
>> 
>> 05:32  running `sudo ceph osd pool application enable glance rbd`
>> got me back to healthy on my 'glance' pool
>> 05:33  these are the two first papercuts
>> 05:33  next - Manager for service cinder-volume cinder@cinder-ceph
>> is reporting problems, not sending heartbeat. Service will appear "down".
>> 05:34   the only pool I see following a deploy is 'glance'
>> https://paste.ubuntu.com/p/Gg5G3Bmhq3/
>> Ubuntu Pastebin
>> 
>> 05:36  when I try to create an instance in openstack I get the good
>> ol' - Error: Failed to perform requested operation on instance "aset", the
>> instance has an error status: Please try again later [Error: Build of
>> instance 13e170cd-6aea-43ed-9ca1-de2ae62c3118 aborted: Volume
>> 72e36907-81df-446c-b580-78bd96134ce0 did not finish being created even
>> after we waited 0 seconds or 1 attempts. And its status is error.].
>> 05:36  possibly there is a bunch of post deploy configuration that
>> need be done here?
>>
>>
>> Thanks
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Openstack User Feedback

[James Beedy]

Here are the bugs:

1) https://bugs.launchpad.net/charms.ceph/+bug/1761214
2) https://bugs.launchpad.net/charms.ceph/+bug/1761208
3) https://bugs.launchpad.net/charm-ceph-fs/+bug/1753640


On Wed, Apr 4, 2018 at 5:52 AM, James Beedy  wrote:

> Hello,
>
> @chrismacnaughton @jamespage @beisner @openstack-charmers ceph <->
> openstack such a broken bone right now.
>
> Please fix.
>
> Here is my bundle https://pastebin.com/gEUYaiFh
>
>
> (From IRC)
> 05:29  heres my deploy, looks great
> 05:29  https://pastebin.com/a2iNrBxv
> 
> jamesbeedy - Pastebin.com
> 
> 05:30  following a (what appears to be successful) deploy, I only
> see a 'glance' pool in ceph, and its in warning due to pg_num > pgp_num
> 05:31  increasing pgp_num gets me a healthy status
> 05:32  follow by another health warning https://paste.ubuntu.com/p/
> zD7HxMz6s6/
> Ubuntu Pastebin
> 
> 05:32  running `sudo ceph osd pool application enable glance rbd`
> got me back to healthy on my 'glance' pool
> 05:33  these are the two first papercuts
> 05:33  next - Manager for service cinder-volume cinder@cinder-ceph
> is reporting problems, not sending heartbeat. Service will appear "down".
> 05:34   the only pool I see following a deploy is 'glance'
> https://paste.ubuntu.com/p/Gg5G3Bmhq3/
> Ubuntu Pastebin
> 
> 05:36  when I try to create an instance in openstack I get the good
> ol' - Error: Failed to perform requested operation on instance "aset", the
> instance has an error status: Please try again later [Error: Build of
> instance 13e170cd-6aea-43ed-9ca1-de2ae62c3118 aborted: Volume
> 72e36907-81df-446c-b580-78bd96134ce0 did not finish being created even
> after we waited 0 seconds or 1 attempts. And its status is error.].
> 05:36  possibly there is a bunch of post deploy configuration that
> need be done here?
>
>
> Thanks
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju's dependencies, juju/utils and a road forward

[roger peppe]

I agree wholeheartedly about splitting up the utils package.

We talked about this potential issue when it was initially created
(and named "trivial", for trivial functionality with no better place
and no dependencies).

The dependency graph is crucial - one of the main reasons that utils
is problematic is because it has so many external dependencies.

> I'd like to move juju to only use "stable" dependency branches. No more
> '-unstable'.

It's perhaps worth observing that "unstable" is the default for any
package that's not under gopkg.in. At current count there are 99 such
packages in juju's dependencies, all potentially unstable, so I'm not
sure it's worth picking out the
explicit gopkg.in unstable paths for blame here.

Of course, this depends on how careful package authors are to maintain
backward compatibility. Some are pretty good, some not so much.

That said, I agree that using explicitly stable dependencies is a
worthwhile goal. In particular, the ongoing move towards using
bakery.v2-unstable is probably not a great direction, because that
uses a particular commit that just happens to be the one that the
charm store currently uses. Given that the charmstore dependency is
only there for some tests, I'd suggest that the effort might be better
expended in changing those tests so that they don't need to import the
charmstore code directly (for example by writing a fake charmstore
server, or making the tests talk to an external charmstore server -
or, ideally, both). Then it becomes more feasible to make the Juju
code use bakery.v2.

What I'd really like is for us to fast forward a year so that we can
use the the upcoming vgo dependency stuff, but time travel isn't
currently an option, sadly.

One important thing is to try to commit to API stability as much as
possible. A large number (maybe most) of the issues come from places
where APIs have been changed without regard for backward
compatibility. Using semantic versions to tag releases is also a good
idea in general.



On 4 April 2018 at 01:52, Tim Penhey  wrote:
> Hi folks,
>
> Juju has a problem with its dependencies. We have been trying to upgrade
> a number of our dependencies recently have have been hitting road
> blocks. Mostly because of changes to common libraries that are
> incompatible with other libraries that we use.
>
> I'm pretty sure that the root of all these problems is the juju/utils
> package. It has become a dumping ground for any common functions that
> packages may want to share. However these common functions are changed
> arbitrarily with only thoughts around how they impact a subset of the
> downstreams of juju/utils.
>
> I think that the only sane way forward is to move all the functionality
> we care about out of juju/utils into more cohesive, smaller, packages
> that have meaningful names and you should be able to determine what they do.
>
> Where the current clashes came from were a few places.
>  1) we wanted to change our mgo dependency
>  2) a new file path utility function was wanted
>  3) the debugstatus package inside utils was updated in a backward
> incompatible way
>
> The root problem here is that the utils package tries to do too many
> things. Any package called "utils" should be a warning, and we should
> have listened to Dave Cheney when he brought this up originally.
>
> I think the way forward is to break up the utils package. I'd like to
> propose that we don't add anything new to the utils package, and only
> deletions are allowed. We create new packages that contain the
> functionality we require, and have them be much more controlled on their
> own dependencies.
>
> Thoughts?
>
> Tim
>
> --
> 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: Juju's dependencies, juju/utils and a road forward

[John Meinel]

I agree with breaking up utils. I've certainly read similar comments
elsewhere that calling something 'utils' inherently causes issues like
this, and it seems to fit with our experience.

I also agree that X stable depending on Y unstable doesn't seem right.
Though we're also very bad at ever making a genuine release of
dependencies. (it's a lot of overhead if nobody else is actually consuming
them)

There are probably other small things like it is "mgo/bson" where bson
should really be it's own package.

Also some questions about how well packages avoid leaking. (charmstore uses
mgo as a backend. if it doesn't expose those types then we probably don't
care if some of our tree depends on it while the other part doesn't. At
least as a transition phase.)

John
=:->

On Apr 4, 2018 06:19, "Tim Penhey"  wrote:

Which then begs the question...

Why do we have stable gopkg.in branches depending on unstable branches?

i.e. gopkg.in/juju/charmstore.v5 depending on
gopkg.in/macaroon-bakery.v2-unstable?

This seems to smell bad.



Tim


On 04/04/18 14:17, Tim Penhey wrote:
> As a follow on...
>
> I'd like to move juju to only use "stable" dependency branches. No more
> '-unstable'.
>
> Tim
>
> On 04/04/18 12:52, Tim Penhey wrote:
>> Hi folks,
>>
>> Juju has a problem with its dependencies. We have been trying to upgrade
>> a number of our dependencies recently have have been hitting road
>> blocks. Mostly because of changes to common libraries that are
>> incompatible with other libraries that we use.
>>
>> I'm pretty sure that the root of all these problems is the juju/utils
>> package. It has become a dumping ground for any common functions that
>> packages may want to share. However these common functions are changed
>> arbitrarily with only thoughts around how they impact a subset of the
>> downstreams of juju/utils.
>>
>> I think that the only sane way forward is to move all the functionality
>> we care about out of juju/utils into more cohesive, smaller, packages
>> that have meaningful names and you should be able to determine what they
do.
>>
>> Where the current clashes came from were a few places.
>>  1) we wanted to change our mgo dependency
>>  2) a new file path utility function was wanted
>>  3) the debugstatus package inside utils was updated in a backward
>> incompatible way
>>
>> The root problem here is that the utils package tries to do too many
>> things. Any package called "utils" should be a warning, and we should
>> have listened to Dave Cheney when he brought this up originally.
>>
>> I think the way forward is to break up the utils package. I'd like to
>> propose that we don't add anything new to the utils package, and only
>> deletions are allowed. We create new packages that contain the
>> functionality we require, and have them be much more controlled on their
>> own dependencies.
>>
>> Thoughts?
>>
>> Tim
>>
>

--
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: Juju's dependencies, juju/utils and a road forward

[Tim Penhey]

Which then begs the question...

Why do we have stable gopkg.in branches depending on unstable branches?

i.e. gopkg.in/juju/charmstore.v5 depending on
gopkg.in/macaroon-bakery.v2-unstable?

This seems to smell bad.


Tim

On 04/04/18 14:17, Tim Penhey wrote:
> As a follow on...
> 
> I'd like to move juju to only use "stable" dependency branches. No more
> '-unstable'.
> 
> Tim
> 
> On 04/04/18 12:52, Tim Penhey wrote:
>> Hi folks,
>>
>> Juju has a problem with its dependencies. We have been trying to upgrade
>> a number of our dependencies recently have have been hitting road
>> blocks. Mostly because of changes to common libraries that are
>> incompatible with other libraries that we use.
>>
>> I'm pretty sure that the root of all these problems is the juju/utils
>> package. It has become a dumping ground for any common functions that
>> packages may want to share. However these common functions are changed
>> arbitrarily with only thoughts around how they impact a subset of the
>> downstreams of juju/utils.
>>
>> I think that the only sane way forward is to move all the functionality
>> we care about out of juju/utils into more cohesive, smaller, packages
>> that have meaningful names and you should be able to determine what they do.
>>
>> Where the current clashes came from were a few places.
>>  1) we wanted to change our mgo dependency
>>  2) a new file path utility function was wanted
>>  3) the debugstatus package inside utils was updated in a backward
>> incompatible way
>>
>> The root problem here is that the utils package tries to do too many
>> things. Any package called "utils" should be a warning, and we should
>> have listened to Dave Cheney when he brought this up originally.
>>
>> I think the way forward is to break up the utils package. I'd like to
>> propose that we don't add anything new to the utils package, and only
>> deletions are allowed. We create new packages that contain the
>> functionality we require, and have them be much more controlled on their
>> own dependencies.
>>
>> Thoughts?
>>
>> Tim
>>
> 

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

Re: Juju's dependencies, juju/utils and a road forward

[Tim Penhey]

As a follow on...

I'd like to move juju to only use "stable" dependency branches. No more
'-unstable'.

Tim

On 04/04/18 12:52, Tim Penhey wrote:
> Hi folks,
> 
> Juju has a problem with its dependencies. We have been trying to upgrade
> a number of our dependencies recently have have been hitting road
> blocks. Mostly because of changes to common libraries that are
> incompatible with other libraries that we use.
> 
> I'm pretty sure that the root of all these problems is the juju/utils
> package. It has become a dumping ground for any common functions that
> packages may want to share. However these common functions are changed
> arbitrarily with only thoughts around how they impact a subset of the
> downstreams of juju/utils.
> 
> I think that the only sane way forward is to move all the functionality
> we care about out of juju/utils into more cohesive, smaller, packages
> that have meaningful names and you should be able to determine what they do.
> 
> Where the current clashes came from were a few places.
>  1) we wanted to change our mgo dependency
>  2) a new file path utility function was wanted
>  3) the debugstatus package inside utils was updated in a backward
> incompatible way
> 
> The root problem here is that the utils package tries to do too many
> things. Any package called "utils" should be a warning, and we should
> have listened to Dave Cheney when he brought this up originally.
> 
> I think the way forward is to break up the utils package. I'd like to
> propose that we don't add anything new to the utils package, and only
> deletions are allowed. We create new packages that contain the
> functionality we require, and have them be much more controlled on their
> own dependencies.
> 
> Thoughts?
> 
> Tim
> 

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

Re: More juju upgrade-juju failings

[Sandor Zeestraten]

Hi Nicholas,

Thanks for the input. I wrote up a short blog post about our experiences
going from 2.1 to 2.3. Hopefully it provides some feedback and can be
helpful for others in the same position.

http://zeestrataca.com/posts/upgrading-juju/

Regards
--
Sandor Zeestraten

On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Sandor, re:sharing experiences, if you want to frame some scenarios you've
> had trouble with, please feel free to share those. Distilling it down into
> a repeatable deployment -> upgrade will help us understand and account for
> it. As Tim mentioned, tools like juju-upgrader are generally candidates for
> incorporation into juju itself, provided they prove valuable to the
> community at large. We always welcome any PR's, but especially so for
> improvements that add this functionality.
>
> Nicholas
>
> On 03/21/2018 08:43 PM, Tim Penhey wrote:
>
>> Hi Sandor,
>>
>> Streamlining upgrades is definitely on the team's road-map. We are aware
>> of the juju-upgrader plugin, and will be looking to incorporate some of
>> that functionality into the core codebase.
>>
>> The core team has worked on better upgrade testing as part of our CI,
>> which enables more test scenarios to help discover issues between more
>> versions.
>>
>> Cheers,
>> Tim
>>
>> On 22/03/18 05:32, Sandor Zeestraten wrote:
>>
>>> Is this shared google doc open for external contributors?
>>>
>>> After spending a while upgrading our 2.1.x environments to 2.3.x and
>>> hitting some bugs along the way in staging (see below), I'd agree that
>>> the process needs a bit of love and wouldn't mind sharing some
>>> experiences.
>>>
>>> Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a
>>> couple of episodes back, but I haven't seen it mentioned anywhere else
>>> yet. Are those tools supposed to deal with some of these issues and
>>> eventually be rolled into juju-core?
>>>
>>> https://bugs.launchpad.net/juju/+bug/1746265
>>> https://bugs.launchpad.net/juju/+bug/1748294
>>> https://bugs.launchpad.net/juju/+bug/1697936
>>>
>>> Regards
>>> --
>>> Sandor Zeestraten
>>>
>>> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth >> > wrote:
>>>
>>>
>>>  I think this UX on the upgrade process has obvious problems. Nobody
>>>  should have to guess at what to do, in which sequence.
>>>
>>>  Can I suggest that we have a shared Google doc to mock up a nice
>>>  experience starting with the simple command 'juju upgrade' which
>>> then
>>>  walks people through the process, including the distinction between
>>>  upgrading charms, agents and controllers, as well as the ability to
>>> do
>>>  aerospace-grade upgrades through live migration to newer
>>> controllers?
>>>
>>>  Mark
>>>
>>>  On 02/27/2018 11:26 PM, Tim Penhey wrote:
>>>  > Hi Daniel,
>>>  >
>>>  > The issue here is that you are upgrading the default model, not
>>> the
>>>  > controller model itself.
>>>  >
>>>  > I think we could make the error messaging more clear, and also
>>>  have the
>>>  > command also check the controller version before showing a lot of
>>>  > baffling output.
>>>  >
>>>  > What you need to do is upgrade the controller model first, so
>>> either
>>>  > switch to it or run:
>>>  >
>>>  >   juju upgrade-juju -m controller --agent-version 2.3.3
>>>  >
>>>  > Cheers,
>>>  > Tim
>>>  >
>>>  > On 28/02/18 11:19, Daniel Bidwell wrote:
>>>  >> I am running on juju 2.3.3-xenial-amd64 and my controllers are
>>>  running
>>>  >> in VMware Vsphere with version 2.3.2.  I thought that it would
>>> be a
>>>  >> good thing for me to upgrade the controllers.
>>>  >>
>>>  >> I have a controller, "juju switch" generates:
>>>  >> bannercontroller:admin/default
>>>  >>
>>>  >> and juju status generates:
>>>  >> ModelControllerCloud/Region  Version
>>>   SLA
>>>  >> default  bannercontroller  myvscloud/New
>>>  Datacenter  2.3.2unsupported
>>>  >>
>>>  >> App  Version  Status  Scale  Charm  Store  Rev  OS  Notes
>>>  >>
>>>  >> Unit  Workload  Agent  Machine  Public address  Ports  Message
>>>  >>
>>>  >> Machine  State  DNS  Inst id  Series  AZ  Message
>>>  >>
>>>  >> doing "juju upgrade-juju --agent-version 2.3.3 --debug"
>>> generates:
>>>  >>
>>>  >> 17:16:19 INFO  juju.cmd supercommand.go:56 running juju [2.3.3 gc
>>>  go1.9.2]
>>>  >> 17:16:19 DEBUG juju.cmd supercommand.go:57   args:
>>>  []string{"/snap/juju/3452/bin/juju", "upgrade-juju",
>>>  "--agent-version", "2.3.3", "--debug"}
>>>  >> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses:
>>>  [10.1.61.239:17070 ]
>>>  >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed
>>>  

Re: More juju upgrade-juju failings

[Sandor Zeestraten]

Hi Nicholas,

Thanks for the input. I wrote up a short blog post about our experiences
going from 2.1 to 2.3. Hopefully it provides some feedback and can be
helpful for others in the same position.

http://zeestrataca.com/posts/upgrading-juju/

Regards
--
Sandor Zeestraten

On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Sandor, re:sharing experiences, if you want to frame some scenarios you've
> had trouble with, please feel free to share those. Distilling it down into
> a repeatable deployment -> upgrade will help us understand and account for
> it. As Tim mentioned, tools like juju-upgrader are generally candidates for
> incorporation into juju itself, provided they prove valuable to the
> community at large. We always welcome any PR's, but especially so for
> improvements that add this functionality.
>
> Nicholas
>
> On 03/21/2018 08:43 PM, Tim Penhey wrote:
>
>> Hi Sandor,
>>
>> Streamlining upgrades is definitely on the team's road-map. We are aware
>> of the juju-upgrader plugin, and will be looking to incorporate some of
>> that functionality into the core codebase.
>>
>> The core team has worked on better upgrade testing as part of our CI,
>> which enables more test scenarios to help discover issues between more
>> versions.
>>
>> Cheers,
>> Tim
>>
>> On 22/03/18 05:32, Sandor Zeestraten wrote:
>>
>>> Is this shared google doc open for external contributors?
>>>
>>> After spending a while upgrading our 2.1.x environments to 2.3.x and
>>> hitting some bugs along the way in staging (see below), I'd agree that
>>> the process needs a bit of love and wouldn't mind sharing some
>>> experiences.
>>>
>>> Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a
>>> couple of episodes back, but I haven't seen it mentioned anywhere else
>>> yet. Are those tools supposed to deal with some of these issues and
>>> eventually be rolled into juju-core?
>>>
>>> https://bugs.launchpad.net/juju/+bug/1746265
>>> https://bugs.launchpad.net/juju/+bug/1748294
>>> https://bugs.launchpad.net/juju/+bug/1697936
>>>
>>> Regards
>>> --
>>> Sandor Zeestraten
>>>
>>> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth >> > wrote:
>>>
>>>
>>>  I think this UX on the upgrade process has obvious problems. Nobody
>>>  should have to guess at what to do, in which sequence.
>>>
>>>  Can I suggest that we have a shared Google doc to mock up a nice
>>>  experience starting with the simple command 'juju upgrade' which
>>> then
>>>  walks people through the process, including the distinction between
>>>  upgrading charms, agents and controllers, as well as the ability to
>>> do
>>>  aerospace-grade upgrades through live migration to newer
>>> controllers?
>>>
>>>  Mark
>>>
>>>  On 02/27/2018 11:26 PM, Tim Penhey wrote:
>>>  > Hi Daniel,
>>>  >
>>>  > The issue here is that you are upgrading the default model, not
>>> the
>>>  > controller model itself.
>>>  >
>>>  > I think we could make the error messaging more clear, and also
>>>  have the
>>>  > command also check the controller version before showing a lot of
>>>  > baffling output.
>>>  >
>>>  > What you need to do is upgrade the controller model first, so
>>> either
>>>  > switch to it or run:
>>>  >
>>>  >   juju upgrade-juju -m controller --agent-version 2.3.3
>>>  >
>>>  > Cheers,
>>>  > Tim
>>>  >
>>>  > On 28/02/18 11:19, Daniel Bidwell wrote:
>>>  >> I am running on juju 2.3.3-xenial-amd64 and my controllers are
>>>  running
>>>  >> in VMware Vsphere with version 2.3.2.  I thought that it would
>>> be a
>>>  >> good thing for me to upgrade the controllers.
>>>  >>
>>>  >> I have a controller, "juju switch" generates:
>>>  >> bannercontroller:admin/default
>>>  >>
>>>  >> and juju status generates:
>>>  >> ModelControllerCloud/Region  Version
>>>   SLA
>>>  >> default  bannercontroller  myvscloud/New
>>>  Datacenter  2.3.2unsupported
>>>  >>
>>>  >> App  Version  Status  Scale  Charm  Store  Rev  OS  Notes
>>>  >>
>>>  >> Unit  Workload  Agent  Machine  Public address  Ports  Message
>>>  >>
>>>  >> Machine  State  DNS  Inst id  Series  AZ  Message
>>>  >>
>>>  >> doing "juju upgrade-juju --agent-version 2.3.3 --debug"
>>> generates:
>>>  >>
>>>  >> 17:16:19 INFO  juju.cmd supercommand.go:56 running juju [2.3.3 gc
>>>  go1.9.2]
>>>  >> 17:16:19 DEBUG juju.cmd supercommand.go:57   args:
>>>  []string{"/snap/juju/3452/bin/juju", "upgrade-juju",
>>>  "--agent-version", "2.3.3", "--debug"}
>>>  >> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses:
>>>  [10.1.61.239:17070 ]
>>>  >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed
>>>