Re: Juju 2.0-rc3 is here!

'"upload-tools strikes back" > cannot upgrade with streams' > https://bugs.launchpad.net/juju/+bug/1631529 > > On Fri, Oct 7, 2016 at 1:51 PM, Matt Rae <matt@canonical.com> wrote: > > Hi, I'm testing an upgrade between juju 2.0 rc2 and rc3. > > &

Re: Juju 2.0-rc3 is here!

Hi, I'm testing an upgrade between juju 2.0 rc2 and rc3. Should 'juju upgrade-juju -m default' upgrade to rc3? So far I'm seeing 'no upgrades available' $ juju model-config agent-version 2.0-rc2 $ juju --version 2.0-rc3-xenial-amd64 $ juju upgrade-juju no upgrades available $ juju upgrade-juju

Re: Juju 2.0-rc3 is here!

Hi, I'm testing an upgrade between juju 2.0 rc2 and rc3. Should 'juju upgrade-juju -m default' upgrade to rc3? So far I'm seeing 'no upgrades available' $ juju model-config agent-version 2.0-rc2 $ juju --version 2.0-rc3-xenial-amd64 $ juju upgrade-juju no upgrades available $ juju upgrade-juju

Re: maas grub issue

Hi Daniel, if the HP servers have iLO, they are often able to use the IPMI power setting with IPMI_2_0. I've seen some older versions of iLO seem to require using the "HP Moonshot iLO4 (IPMI)" power setting. But after updating those same servers to the latest version of iLO, the normal IPMI power

Re: Automatic hook retries in Juju 2.0

Hi Adam, I've also found that debugging environments was difficult with hook retrying on. I've disabled it like this: juju set-model-config automatically-retry-hooks=false On Thu, Jun 30, 2016 at 11:05 AM, Adam Collard wrote: > Did we get a way of disabling this

Re: [Maas-devel] no default route for lxc containers deployed with juju/maas 2.0

> > On 7 June 2016 at 07:08, Matt Rae <matt@canonical.com> wrote: > >> Hi, I'm deploying services into lxc containers using Juju 2.0 beta8 and >> MAAS 2.0 beta6. >> >> The containers are being created with 3 interfaces with separate subnets >> which are b

incorrect private address when using manual provider

Hi we're seeing an issue where the juju private-address is chosen incorrectly when using the manual provider on a host with multiple interfaces. Are there any details regarding how the private-address is chosen when using the manual provider? Matt -- Juju mailing list Juju@lists.ubuntu.com

Re: bootstrap constraints

for the environment within, but we haven't fully worked through how we would spell that. John =:- On Aug 27, 2015 10:22 AM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.08.2015 07:29, Matt Rae wrote: Hi All, when using 'juju bootstrap

bootstrap constraints

Hi All, when using 'juju bootstrap --constraints' the constraint is used for bootstrap, but the constraint is also set on the environment for future machines. Is it helpful to set the additional environment constraint? So far I've frequently seen the bootstrap constraint used to choose which

Re: requirements for

Also noting that running MAAS in a vm has worked fine in my experience. Are there any pitfalls with using a vm? Matt On Fri, Mar 27, 2015 at 8:22 AM, Rafael Gonzalez rafael.gonza...@canonical.com wrote: Hi Stephen, MAAS would be your first node, if configured robustly enough, it can also

Re: PXE hanging

Hi Stephen, typically you shouldn't need to manually add nodes to MAAS. The first time the nodes successfully PXE, they should appear in MAAS if the connectivity is correct. If the nodes aren't able to PXE from MAAS, I think that is the problem. If you run 'dhcpdump' on the MAAS server, do you

Re: disabling upgrades on new machines by default?

I don't think the upgrade matters as much as speed. I feel like most users know to manage updates already, with their own policies, and that the fast user experience is important. Even if juju upgrades initially, users will still need to manage updates after, so I'm not sure how much the initial

Re: disabling upgrades on new machines by default?

:55 PM, Matt Rae matt@canonical.com wrote: I don't think the upgrade matters as much as speed. I feel like most users know to manage updates already, with their own policies, and that the fast user experience is important. Even if juju upgrades initially, users will still need to manage

Re: getting rid of all-machines.log

Many operations teams already have a standard log collecting systems. I think it would be best to be flexible enough to work in environments with existing systems. Standard ways are logging to syslog so any syslog implementation can be used, or logging to stdout so a supervisor like djb