On 28/11/16 21:53, James Beedy wrote:
> Perfect deploys across lxd, ec2, and manual providers!
>
> EC2 - http://paste.ubuntu.com/23551492/
> LXD - http://paste.ubuntu.com/23551496/
> Manual - http://paste.ubuntu.com/23551498/
That's how we like it :)
--
Juju-dev mailing list
Juju-dev@lists.ubunt
Perfect deploys across lxd, ec2, and manual providers!
EC2 - http://paste.ubuntu.com/23551492/
LXD - http://paste.ubuntu.com/23551496/
Manual - http://paste.ubuntu.com/23551498/
On Mon, Nov 28, 2016 at 5:28 PM, Anastasia Macmood <
anastasia.macm...@canonical.com> wrote:
>
>
> On 29/11/16 11:2
On 29/11/16 11:26, James Beedy wrote:
> Just wanted to let everyone know (thanks to lots of help) that I've
> rendered a successful manual provider deploy :-)
\o/
> This will be my first production deploy for CreativeDrive, you can
> take a peek at the success here -> http://paste.ubuntu.com/2355
Just wanted to let everyone know (thanks to lots of help) that I've
rendered a successful manual provider deploy :-) This will be my first
production deploy for CreativeDrive, you can take a peek at the success
here -> http://paste.ubuntu.com/23551183/
I've created a temporary repo for my prm-web
On 28/11/16 17:21, Merlijn Sebrechts wrote:
>
> What I suggest is that you stop trying to make Juju work in 'the
> ocean' and focus the manual environment efforts on one thing: a
> multi-machine LXD provider. *Fix the LXD networking and DNS issues and
> tell everyone to only use LXD containers in a
Merlin,
Thanks for your insight here, and I totally agree with you, "running
everything in LXD containers is a very good starting point" - simply
because we can guarantee that everything works as tested/expected, right?
To the extent of trying to hack lxd/lxc networking, I think a generic
openvsw
Super difficult to document 'the ocean', there will always be fraying at
the edges that what worked on clouds fails in the manual case.
Mark
On 28/11/16 15:49, Rick Harding wrote:
> That's very true on the items that are different. I wonder if we could
> work with the CPC team and note the thing
That's very true on the items that are different. I wonder if we could work
with the CPC team and note the things that are assumed promises when using
cloud images so that it'd be easy to build a "patch" for manually
provisioned machines. If we know specific packages or configuration is
there on ou
>From what I can tell, there are a number of places where these manual
machines differ from our "standard" install. I think the charms can be
written defensively around this, but its why you're running into more
issues than you normally would.
1. 'noexec' for /tmp. I've heard of this, but as la
Was a bit flustered earlier when I sent off this email, I've looked a bit
closer at each of the individual problems, thought I would report back with
my findings.
1. Job for systemd-sysctl.service failed because the control process exited
- This is an error I'm seeing when installing juju (not
I'm trying to get an application I've charmed up, deployed for one of our
larger clients on their private cloud infrastructure (Ubuntu 14.04 and
16.04 machines). I'm experiencing a few different issues that leave almost
everything in a state of error. Controller, charms, client, almost
everything s
11 matches
Mail list logo
