Re: Aggregate all bundle.yaml | API endpoint

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

Re: Aggregate all bundle.yaml | API endpoint

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

Re: Aggregate all bundle.yaml | API endpoint

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

Re: Aggregate all bundle.yaml | API endpoint

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

Re: Aggregate all bundle.yaml | API endpoint

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

Re: Aggregate all bundle.yaml | API endpoint

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

Re: Aggregate all bundle.yaml | API endpoint

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

Re: Aggregate all bundle.yaml | API endpoint

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

Re: juju bootstrap to a particular subnet

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.

Re: Juju 2.4.0 has been released

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

Re: Juju 2.4.0 has been released

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:

Re: Juju 2.4.0 has been released

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:

Re: Juju 2.4.0 has been released

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

Re: Juju 2.4.0 has been released

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

Re: Juju 2.4.0 has been released

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

Re: JAAS outage this afternoon

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

Re: juju bootstrap to a particular subnet

@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

Re: juju bootstrap to a particular subnet

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

Re: Charm series in API URL

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

Re: Charm series in API URL

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

Re: LXD on Manual incorrect resolv.conf

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

Re: LXD on Manual incorrect resolv.conf

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

Re: LXD on Manual incorrect resolv.conf

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

Re: LXD on Manual incorrect resolv.conf

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

Re: LXD on Manual incorrect resolv.conf

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

Re: Aggregate all bundle.yaml | API endpoint

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

Re: Charm series in API URL

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

Re: Aggregate all bundle.yaml | API endpoint

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

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

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

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

*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

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

*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

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

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

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

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

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

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

Re: Juju 2.4-rc2 has been released

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

Re: Juju 2.4-rc2 has been released

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

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

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

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

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

Re: Please promulgate Mattermost charm

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 >

Re: EC2 availability zones and bundles

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

Re: EC2 availability zones and bundles

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

Re: Please promulgate Mattermost charm

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

Re: Please promulgate Mattermost charm

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

Re: Please promulgate Mattermost charm

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 >

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

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

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

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

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

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

RE: Mongo DB on the Juju controller

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

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 wrote: > All, > > We are trying to access the MongoDB instance within the juju controller.

Re: 18.05 OpenStack Charms release

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 >

Re: Juju 2.4-rc1 Released

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

Re: Juju 2.4-rc1 Released

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

Re: Juju 2.4-rc1 Released

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

Re: Juju 2.4-rc1 Released

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

Re: Juju 2.4-rc1 Released

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

Re: Aggregate all bundle.yaml | API endpoint

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

Re: Aggregate all bundle.yaml | API endpoint

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

Re: Major Roadblocks - real life use cases

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

Re: Major Roadblocks - real life use cases

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,

Re: Major Roadblocks - real life use cases

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

Re: SLURM Charms New Upstream

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

Re: Juju, OpenStack and Packet.net @KubeCon Copenhagen

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

Re: Additional bindings

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

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

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

Re: SSH to machines from add-user

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

Re: Blog post about expanding Ceph clusters with Juju

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

Re: canonical-kubernetes - Adding worker get stuck

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

Re: Error conjure-up canonical-kubernetes

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

Re: We are pulling he 2.3.6 agents

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

Re: We are pulling he 2.3.6 agents

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

Re: We are pulling he 2.3.6 agents

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

Re: We are pulling he 2.3.6 agents

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

Re:

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

Re:

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

Re:

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

Re: Should 'juju status' always include a timestamp

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

Re: Should 'juju status' always include a timestamp

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

Re: Should 'juju status' always include a timestamp

+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

Re: Cinder-Ceph Multi-Backend Example

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

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

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,

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

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.

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

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

Re: Cinder-Ceph Multi-Backend Example

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

Re: Implement aws style user-data

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

Re: Implement aws style user-data

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

Re: Implement aws style user-data

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

Re: Openstack User Feedback

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

Re: More juju upgrade-juju failings

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

Re: More juju upgrade-juju failings

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

Re: More juju upgrade-juju failings

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,

Re: More juju upgrade-juju failings

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,

Re: Openstack User Feedback

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)

Re: Openstack User Feedback

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

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

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

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

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

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

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

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

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

Re: More juju upgrade-juju failings

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

Re: More juju upgrade-juju failings

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

  1   2   3   4   5   6   7   8   9   10   >