from:"Matt Rae"

Re: Juju 2.0-rc3 is here!

2016-10-07 Thread Matt Rae

Thanks Curtis! following your steps and setting the agent-stream=devel, I
was able to upgrade the controller and default models to rc3

Matt

On Fri, Oct 7, 2016 at 1:59 PM, Curtis Hovey-Canonical <cur...@canonical.com
> wrote:

> Hi Matt,
>
> You, and several of us, are victims of '"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.
> >
> > 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 --agent-version 2.0-rc3
> > ERROR no matching tools available
>
> Do you see this:
> $ juju model-config -m controller agent-stream
> released
>
> ^ No, the juju client selected devel streams without telling the controller
>
> WORK AROUND
>
> Tell the juju controller to use devel streams. Eg, to upgrade my own
> deployment, I I set the streams to devel, then upgrade the controller
> than the hosted model.
>
> $ juju model-config -m controller agent-stream=devel
> $ juju upgrade-juju -m controller
> started upgrade to 2.0-rc3
> $ juju upgrade-juju -m default
> started upgrade to 2.0-rc3
>
> When 2.0.0 is released, switch the streams to released.
> $ juju model-config -m controller agent-stream=released
>
> Then upgrade as normal.
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
-- 
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.0-rc3 is here!

2016-10-07 Thread Matt Rae

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 --agent-version 2.0-rc3
ERROR no matching tools available

Matt



On Fri, Oct 7, 2016 at 10:07 AM, Christian Muirhead <
christian.muirh...@canonical.com> wrote:

> It indicates that that unit is the leader for the application. It's a bit
> academic in the status you pasted, since each application only has one
> unit, but I can see it being useful if you had scaled out a bit.
>
> Cheers,
> Christian
>
> On Fri, Oct 7, 2016 at 5:59 PM Adam Israel 
> wrote:
>
>> It looks like rc3 introduced a minor change in the status output. Each
>> unit has an asterisk next to its name, i.e., mariadb/0* (full output in
>> pastebin). What is the asterisk meant to represent?
>>
>> http://pastebin.ubuntu.com/23289710/
>>
>> On Thu, Oct 6, 2016 at 5:28 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>> On Fri, Oct 7, 2016 at 6:15 AM Curtis Hovey-Canonical <
>> cur...@canonical.com> wrote:
>>
>> A new development release of Juju, 2.0-rc3, is here!
>>
>>
>> ## What's new?
>>
>> * For an AWS VPC account juju will create a t2.medium for controller
>>   instances by default now. Non-controller instances are unchanged for
>>   now, and remain m3.medium by default. Controller instance root disk
>>   now defaults to 32GiB, but can be overridden with constraints.
>> * Shorten the hostnames we apply to instances created by the OpenStack
>>   provider.
>> Example old hostname:
>> juju-fd943864-df2e-4da1-8e7d-5116a87d4e7c-machine-14
>>
>> Example new hostname:
>> Juju-df7591-controller-0
>> * Added support for LXD 2.3 apis
>> * New update-credential command
>> * Added --model-default option to the bootstrap
>> * LXD containers now have proper hostnames set
>>
>>
>> Also, support for the aws/ap-south-1 region has been added.
>>
>> Adam Stokes just found a bug related to this, which prevented him from
>> being able to destroy his rc2 controller with an rc3 client. I'll fix this
>> for 2.0, but in the mean time I recommend you destroy your controller
>> before upgrading the client.
>>
>> If you do upgrade the client, then you will need to modify
>> ~/.local/share/juju/bootstrap-config.yaml, fixing the endpoint cached in
>> there. You can find the correct value by running "juju show-cloud aws", and
>> picking out the value associated with the region you bootstrapped.
>>
>> Cheers,
>> Andrew
>>
>>
>> ## How do I get it?
>>
>> If you are running Ubuntu, you can get it from the juju devel ppa:
>>
>> sudo add-apt-repository ppa:juju/devel
>> sudo apt-get update; sudo apt-get install juju-2.0
>>
>> Windows, Centos, and MacOS users can get a corresponding installer at:
>>
>> https://launchpad.net/juju/+milestone/2.0-rc3
>>
>>
>> ## Feedback Appreciated!
>>
>> We encourage everyone to subscribe the mailing list at
>> juju@lists.ubuntu.com and join us on #juju on freenode. We would love to
>> hear
>> your feedback and usage of juju.
>>
>>
>> ## Anything else?
>>
>> You can read more information about what's in this release by viewing the
>> release notes here:
>>
>> https://jujucharms.com/docs/devel/temp-release-notes
>>
>>
>> --
>> Curtis Hovey
>> Canonical Cloud Development and Operations
>> http://launchpad.net/~sinzui
>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju-dev
>>
>> --
>> 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-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju-dev
>>
>
> --
> 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.0-rc3 is here!

2016-10-07 Thread Matt Rae

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 --agent-version 2.0-rc3
ERROR no matching tools available

Matt



On Fri, Oct 7, 2016 at 10:07 AM, Christian Muirhead <
christian.muirh...@canonical.com> wrote:

> It indicates that that unit is the leader for the application. It's a bit
> academic in the status you pasted, since each application only has one
> unit, but I can see it being useful if you had scaled out a bit.
>
> Cheers,
> Christian
>
> On Fri, Oct 7, 2016 at 5:59 PM Adam Israel 
> wrote:
>
>> It looks like rc3 introduced a minor change in the status output. Each
>> unit has an asterisk next to its name, i.e., mariadb/0* (full output in
>> pastebin). What is the asterisk meant to represent?
>>
>> http://pastebin.ubuntu.com/23289710/
>>
>> On Thu, Oct 6, 2016 at 5:28 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>> On Fri, Oct 7, 2016 at 6:15 AM Curtis Hovey-Canonical <
>> cur...@canonical.com> wrote:
>>
>> A new development release of Juju, 2.0-rc3, is here!
>>
>>
>> ## What's new?
>>
>> * For an AWS VPC account juju will create a t2.medium for controller
>>   instances by default now. Non-controller instances are unchanged for
>>   now, and remain m3.medium by default. Controller instance root disk
>>   now defaults to 32GiB, but can be overridden with constraints.
>> * Shorten the hostnames we apply to instances created by the OpenStack
>>   provider.
>> Example old hostname:
>> juju-fd943864-df2e-4da1-8e7d-5116a87d4e7c-machine-14
>>
>> Example new hostname:
>> Juju-df7591-controller-0
>> * Added support for LXD 2.3 apis
>> * New update-credential command
>> * Added --model-default option to the bootstrap
>> * LXD containers now have proper hostnames set
>>
>>
>> Also, support for the aws/ap-south-1 region has been added.
>>
>> Adam Stokes just found a bug related to this, which prevented him from
>> being able to destroy his rc2 controller with an rc3 client. I'll fix this
>> for 2.0, but in the mean time I recommend you destroy your controller
>> before upgrading the client.
>>
>> If you do upgrade the client, then you will need to modify
>> ~/.local/share/juju/bootstrap-config.yaml, fixing the endpoint cached in
>> there. You can find the correct value by running "juju show-cloud aws", and
>> picking out the value associated with the region you bootstrapped.
>>
>> Cheers,
>> Andrew
>>
>>
>> ## How do I get it?
>>
>> If you are running Ubuntu, you can get it from the juju devel ppa:
>>
>> sudo add-apt-repository ppa:juju/devel
>> sudo apt-get update; sudo apt-get install juju-2.0
>>
>> Windows, Centos, and MacOS users can get a corresponding installer at:
>>
>> https://launchpad.net/juju/+milestone/2.0-rc3
>>
>>
>> ## Feedback Appreciated!
>>
>> We encourage everyone to subscribe the mailing list at
>> j...@lists.ubuntu.com and join us on #juju on freenode. We would love to
>> hear
>> your feedback and usage of juju.
>>
>>
>> ## Anything else?
>>
>> You can read more information about what's in this release by viewing the
>> release notes here:
>>
>> https://jujucharms.com/docs/devel/temp-release-notes
>>
>>
>> --
>> Curtis Hovey
>> Canonical Cloud Development and Operations
>> http://launchpad.net/~sinzui
>>
>> --
>> 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
>>
>> --
>> Adam Israel, Software Engineer
>> Canonical // Cloud DevOps // Juju // Ecosystem
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju-dev
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: maas grub issue

2016-10-06 Thread Matt Rae

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 setting seems to be more
reliable.

For servers that don't support IPMI, you could use the MANUAL power
setting. In that case you would power the node on manually when
commissioning and deploying. Additionally MAAS 2.0 has support for several
smart PDUs. If you use a smart PDU, MAAS can connect to the PDU and power
on the particular plug the server is plugged into.

Matt


On Thu, Oct 6, 2016 at 8:39 AM, Daniel Bidwell  wrote:

> I forgot the cross-post to maas-devel until after I sent this one and
> sent it there also.
>
> I have some older servers in my test cluster that will only do
> wakeonlan and not ipmi.  I was told that wakeonlan was no longer
> available in maas 2.0 and was trying to keep my test cluster on the
> same software as my production cluster.  The old servers are HP DL-
> 180's and they only do wakeonlan and something that I have been lead to
> believe is proprietary.  I would love to be wrong about the wakeonlan
> and maas 2.0 though.
>
> On Thu, 2016-10-06 at 08:22 -0700, Mark Shuttleworth wrote:
> > 'scuse the cross-post but I think you'll get a faster answer from
> > maas-devel. I'll start by asking if you've tried MAAS 2.0?
> >
> > Mark
> >
> > On 06/10/16 08:18, Daniel Bidwell wrote:
> > >
> > > I have a maas-1.9.4 with servers with 4 2T disks for data storage
> > > and a
> > > 120GB disk on an onboard controller for the system disk.  Maas is
> > > deploying ubuntu 16.04 on the servers.  Ubuntu 16.04 labels the
> > > 120GB
> > > system disk as /dev/sde, not /dev/sda.  In maas I can define the
> > > /sdev/sde disk as the system disk.
> > >
> > > juju bootstrap deploys the system and installs the OS on /dev/sde1
> > > but
> > > fails to write the grub record to /dev/sde and leaves the disk
> > > unbootable.  The system fails over to booting from an ephemeral
> > > iscsi
> > > file system where I can examine the state of the machine.
> > >
> > > The disk is formated with a GPT partition table which grub will not
> > > write to unless I manually create a small partition as partition 1
> > > with
> > > blocks from 34-2047 and the system partition as partition 2.
> > >
> > > This manual step really not acceptable for deploying from juju and
> > > maas.
> > >
> > > How do I get maas to deploy the system in a way that it will boot
> > > without manual editing?
> >
> >
> --
> 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: Automatic hook retries in Juju 2.0

2016-06-30 Thread Matt Rae

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 'feature'? As I remember from the
> initial ML post, there was a repeated request to be able to disable this
> for certain environments (e.g. dev/test of charms).
>
> Many charms have race conditions in their hook execution which aren't seen
> through regular use of the Juju CLI client, but other Juju API drivers
> (e.g. Autopilot) expose.
>
> Although automatic hook retries may well negate transient network issues,
> they risk hiding these kinds of bugs. As a charm author I want Juju to help
> me find these bugs, so have it fail when I mess up. Papering over them
> gives me a false sense of security.
>
>
> On Thu, 30 Jun 2016 at 17:27 Bogdan Teleaga <
> btele...@cloudbasesolutions.com> wrote:
>
>> Hey Casey,
>>
>> They are all retried using the same policy.
>>
>> The constants that control the delay are here:
>>
>> https://github.com/juju/juju/blob/master/apiserver/retrystrategy/retrystrategy.go#L21
>>
>> Basically it's an exponential backoff with a factor of 2 that starts at 5
>> seconds and has a maximum of 5 minutes, so 5, 10, 20...up to 300 seconds.
>>
>> Iirc attempting a manual retry will reset this timer. It also never gives
>> up.
>>
>> Cheers,
>> Bogdan
>> On Jun 30, 2016, at 6:52 PM, Casey Marshall 
>> wrote:
>>>
>>> What is the intended behavior for automatic hook retries in Juju 2.0?
>>>
>>> Specifically, I'd like to know, as a Juju user:
>>>
>>> Are errors in hooks all retried with the same policy, or are some
>>> retried with a different policy / strategy than others (install, for
>>> example)?
>>>
>>> Is there a limit to the number of times Juju will retry a hook error
>>> before "giving up"?
>>>
>>> What kind of delay can I expect between retries?
>>>
>>> Thanks,
>>> Casey
>>>
>> --
>> 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: [Maas-devel] no default route for lxc containers deployed with juju/maas 2.0

2016-06-07 Thread Matt Rae

 dev eth1 || true
  post-down address del 172.27.72.10/26 dev eth1 || true

auto eth2
iface eth2 inet manual
  pre-up ip address add 172.27.72.74/26 dev eth2 || true
  up ip route replace 172.27.72.64/26 dev eth2 || true
  down ip route del 172.27.72.64/26 dev eth2 || true
  post-down address del 172.27.72.74/26 dev eth2 || true

Host with beta 7:

root@barmiest-jesica:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
dns-nameservers 10.189.69.5
dns-search maas

iface eno1 inet manual

auto br-eno1
iface br-eno1 inet static
address 10.189.69.10/25
gateway 10.189.69.1
mtu 1500
bridge_ports eno1
dns-nameservers 10.189.69.5 8.8.8.8

auto eno2
iface eno2 inet manual
mtu 1500

auto enp2s0f0
iface enp2s0f0 inet manual
bond-master bond0
bond-xmit_hash_policy encap3+4
mtu 1500
bond-lacp_rate fast
bond-miimon 100
bond-mode 802.3ad

auto enp2s0f1
iface enp2s0f1 inet manual
bond-master bond0
bond-xmit_hash_policy encap3+4
mtu 1500
bond-lacp_rate fast
bond-miimon 100
bond-mode 802.3ad

auto enp2s0f2
iface enp2s0f2 inet manual
bond-master bond1
bond-xmit_hash_policy encap3+4
mtu 1500
bond-lacp_rate fast
bond-miimon 100
bond-mode 802.3ad

auto enp2s0f3
iface enp2s0f3 inet manual
bond-master bond1
bond-xmit_hash_policy encap3+4
mtu 1500
bond-lacp_rate fast
bond-miimon 100
bond-mode 802.3ad

auto ens7f0
iface ens7f0 inet manual
bond-master bond2
bond-xmit_hash_policy encap3+4
mtu 1500
bond-lacp_rate fast
bond-miimon 100
bond-mode 802.3ad

auto ens7f1
iface ens7f1 inet manual
bond-master bond2
bond-xmit_hash_policy encap3+4
mtu 1500
bond-lacp_rate fast
bond-miimon 100
bond-mode 802.3ad

auto bond0
iface bond0 inet manual
address 172.27.72.5/26
bond-lacp_rate fast
bond-xmit_hash_policy encap3+4
mtu 1500
bond-mode 802.3ad
hwaddress 0c:c4:7a:8e:ed:30
bond-slaves none
bond-miimon 100

auto br-bond0
iface br-bond0 inet static
address 172.27.72.5/26
mtu 1500
hwaddress 0c:c4:7a:8e:ed:30
bridge_ports bond0

auto bond0:1
iface bond0:1 inet6 static
address fde9:8f83:4a81:1:0:1:0:4/64
bond-lacp_rate fast
bond-xmit_hash_policy encap3+4
mtu 1500
bond-mode 802.3ad
hwaddress 0c:c4:7a:8e:ed:30
bond-slaves none
bond-miimon 100

auto bond1
iface bond1 inet manual
address 172.27.72.69/26
bond-lacp_rate fast
bond-xmit_hash_policy encap3+4
mtu 1500
bond-mode 802.3ad
hwaddress 0c:c4:7a:8e:ed:32
bond-slaves none
bond-miimon 100

auto br-bond1
iface br-bond1 inet static
address 172.27.72.69/26
mtu 1500
hwaddress 0c:c4:7a:8e:ed:32
bridge_ports bond1

auto bond1:1
iface bond1:1 inet6 static
address fde9:8f83:4a81::1:0:4/64
bond-lacp_rate fast
bond-xmit_hash_policy encap3+4
mtu 1500
bond-mode 802.3ad
hwaddress 0c:c4:7a:8e:ed:32
bond-slaves none
bond-miimon 100

auto bond2
iface bond2 inet6 manual
address fd0d:ffe0:5771::1:0:2/64
bond-lacp_rate fast
bond-xmit_hash_policy encap3+4
mtu 1500
bond-mode 802.3ad
hwaddress 0c:c4:7a:b7:2d:96
bond-slaves none
bond-miimon 100

auto br-bond2
iface br-bond2 inet6 static
address fd0d:ffe0:5771::1:0:2/64
mtu 1500
hwaddress 0c:c4:7a:b7:2d:96
bridge_ports bond2

source /etc/network/interfaces.d/*.cfg


On Tue, Jun 7, 2016 at 10:20 AM, Andrew McDermott <
andrew.mcderm...@canonical.com> wrote:

> Hi Matt,
>
> If you still have the setup running please could you attach
> /etc/network/interfaces from the container and the host. Thanks.
>
> 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 bridged to the interfaces on the node hosting the container. I'm
>> noticing that the containers don't have a default route which is should be
>> gateway_ip 10.189.69.1.
>>
>> The node hosting the container has the default route. I'm not sure why
>> the default route isn't also in the container.
>>
>> On the host there is default route with gateway 10.189.69.1
>>
>> $ route -n
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric RefUse
>> Iface
>> 0.0.0.0 10.189.69.1 0.0.0.0 UG0  00
>> br-eno1
>> 10.0.3.00.0.0.0 255.255.255.0   U 0  00
>> lxcbr0
>> 10.189.69.0 0.0.0.0 255.255.255.128 U 0  00
>> br-eno1
>> 172.27.72.0 0.0.0.0 255.255.255.192 U 0  00
>> br-bond0
>> 172.27.72.640.0.0.0 255.

incorrect private address when using manual provider

2016-05-04 Thread Matt Rae

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
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: bootstrap constraints

2015-08-27 Thread Matt Rae

Thanks John and Dimiter. The issue I'm referring to is the one that John
described.

Yeah a solution could be to have separate arguments to set constraints on
bootstrap and on environment. I personally haven't required the additional
environment constraint that you get with 'juju bootstrap --constraint', and
I've always unset it after bootstrapping.

Matt

On Thu, Aug 27, 2015 at 12:19 PM, John Meinel j...@arbash-meinel.com
wrote:

 I think his issue is that he can juju bootstrap --constraints and then
 immediately juju set-env to remove the constraints.  But juju quickstart
 --constraints does a bootstrap and then immediately starts deploying the
 services without a way to unset the constraints that don't apply to all
 machines.

 I do think we've talked about wanting to split the these are the
 constraints for the machine I'm bootstrapping vs these are the
 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 --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 node to bootstrap to, for example 'juju bootstrap
  --constraints tags=juju'. In this case, normally the constraint
  set on the environment needs to be cleared after bootstrap to
  deploy to machines not tagged 'juju'.
 
  With bootstrap --constraints at least we can clear the constraint
  after bootstrap completes, but with quickstart --constraints, there
  doesn't appear to be way to clear the constraint before juju gui
  starts deploying the bundle using the environment constraint which
  I don't want to use for additional machines. So it appears to break
  the use case of using --constraints to bootstrap to a particular
  machine.
 
  Matt
 
 
 Hi Matt,

 When you're saying you're unable to clear the constraints set at
 bootstrap from the environment, do you mean tags specifically, or
 other constraints as well? If the former, but not the latter, read on.

 I've recently discovered there's *no* way to unset a bootstrap (or
 environment) constraint value of type list (e.g. tags=aa,bb,^cc,dd,
 mostly undocumented networks=... and since a few days - spaces=...
 with the same format). This issue appears to have been lurking for a
 long time - just try this:

 $ juju environment set-constraints tags=foo,^bar
 $ juju environment get-constraints
 tags=foo,^bar
 $ juju environment set-constraints tags=   # expected: set to empty
 $ juju environment get-constraints
 tags=foo,^bar

 So, I fixed this on master a few days ago, and in 1.25 it *will* be
 possible to unset list-style constraints (note that, as before, you
 can still set them to different non-empty value).
 If your issue is like described above, you might want to give
 1.25-alpha1 a try.

 Cheers,
 - --
 Dimiter Naydenov dimiter.nayde...@canonical.com
 Juju Core Sapphire team http://juju.ubuntu.com
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (GNU/Linux)

 iQEcBAEBAgAGBQJV3qx5AAoJENzxV2TbLzHwTlMIAJMdw42RU3BY8kvb1Yk4G+6h
 gGn0XEDPyJHmzgB/QLBjcrjW4FBXFGmJuN/vmbO/0uW6niZINBkHwTDT2m82aNan
 uOIBjaMQxM6GQiLcYXqWroWb1V2dKxgfMx9e+5F5ggmmy6fCtcSrGR4TzAfC62VL
 +GXwvv1sLCLudyjBFhAycu6JMLcONrmw9ZWdN0ZAuPwMYGPWqqY/E3WM4Z7FTWv1
 r9Igt14ogoYwG4kzx2K3xzbLkZP4gfr7pJDGSSjaDUh12Y7jXMYklqLKPFrojcEU
 NPU+vLun0jPKVZOwC5QNYDBqFP+eppOdqNPeT+HKjkfgv5RP6C3sK7FXt14HmQI=
 =7Hyn
 -END PGP SIGNATURE-

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

bootstrap constraints

2015-08-26 Thread Matt Rae

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
node to bootstrap to, for example 'juju bootstrap --constraints
tags=juju'. In this case, normally the constraint set on the environment
needs to be cleared after bootstrap to deploy to machines not tagged
'juju'.

With bootstrap --constraints at least we can clear the constraint after
bootstrap completes, but with quickstart --constraints, there doesn't
appear to be way to clear the constraint before juju gui starts deploying
the bundle using the environment constraint which I don't want to use for
additional machines. So it appears to break the use case of using
--constraints to bootstrap to a particular machine.

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

Re: requirements for

2015-03-27 Thread Matt Rae

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
 run Ubuntu Infrastructure services such as Juju and LandScape.  The MAAS
 server should be on bare metal and separate from any of your OpenStack
 services.

 Regards,

 Rafael O. Gonzalez
 Canonical, Solutions Architect
 rgo...@canonical.com



 On Thu, Mar 26, 2015 at 10:08 PM, Stephen step...@artifex360.com wrote:

 Hi,

 What is the hardware requirements for the
 maas-region-controller?

 If OpenStack is installed, which machine
 should it be? block, object, controller, etc?



 Sometimes I cannot explain my problems
 well.

 Cheers,

 Stephen

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

2015-03-27 Thread Matt Rae

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 see the dhcp requests when
the nodes are PXEing?

Matt

On Fri, Mar 27, 2015 at 9:46 AM, Stephen step...@artifex360.com wrote:

 Hi,

 I’m running MAAS and able to hard code the
 Nodes in, but when I try to PXE boot, they
 hang and cannot connect to MAAS.

 Prior to PXE, I confirmed by ICMP that machines
 were getting responses VIA internal routing
 address.

 Could I be missing a config file in MAAS
 main controller?



 Cheers,

 Stephen
 --
 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: disabling upgrades on new machines by default?

2014-10-02 Thread Matt Rae

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

Juju is blazing fast! is more exciting than Juju makes sure I'm updated
initially!

There is something to be said for having the exact same packages on every
unit of a service rather than a few units having some versions, then units
added later getting different versions.

Matt

On Thu, Oct 2, 2014 at 12:27 AM, Samuel Cozannet 
samuel.cozan...@canonical.com wrote:

 Why not put our perception to the test?

 Here
 https://docs.google.com/a/canonical.com/spreadsheets/d/1T-8rf_XxXbvCCRRHT69KtRM5k4oJiHyTEuzbENBU0Js/edit#gid=0
 is a spreadsheet where you can compile your variables. The top line
 summarizes the sum of values. The column that gets green is the one we
 should go for [assuming we are representative]

 Sam

 On Thu, Oct 2, 2014 at 7:45 AM, John Meinel j...@arbash-meinel.com
 wrote:

 So there is the question of what is the user experience, and people
 trying out Juju and it seems slow. Though if it is slow, doesn't that mean
 that images are out of date?

 I just bootstrapped a fresh Ubuntu from Amazon's web interface today, and
 I noticed that apt-get upgrade on there installed a new bash to fix the
 newest major security hole. It seems like it is good to at least apply
 security updates, and I'm not sure if it is easy to only install those.

 John
 =:-

 On Thu, Oct 2, 2014 at 7:51 AM, José Antonio Rey j...@ubuntu.com wrote:

 I believe that, as Jorge mentioned, most users do value having
 everything up to date by default, specially when they may go directly to
 production environments. Devs may also want to use this switch, as it will
 save time during the deployment for testing the charms they have developed.

 I believe that turning on upgrades as a default would be more valued by
 end-users, but that's just a personal opinion.

 --
 José Antonio Rey
 On Oct 1, 2014 2:34 PM, Jorge O. Castro jo...@ubuntu.com wrote:

 On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu
 kapil.thangav...@canonical.com wrote:
  juju can save minutes per machine (especially against release images)
 if we
  turn off upgrades by default.

 There are some updates coming to how we build cloud images that might
 be relevant to this discussion:

 http://blog.utlemming.org/2014/08/archive-triggered-cloud-image-builds.html

 IMO safer and slower makes sense for most people, those of us who need
 speed for demos/conferences will know about this switch.

 --
 Jorge Castro
 Canonical Ltd.
 http://juju.ubuntu.com/ - Automate your Cloud Infrastructure

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




 --
 Samuel Cozannet
 Cloud, Big Data and IoT Strategy Team
 Strategic Program Manager
 Changing the Future of Cloud
 Ubuntu http://ubuntu.com / Canonical http://canonical.com UK LTD
 samuel.cozan...@canonical.com
 +33 616 702 389


 --
 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: disabling upgrades on new machines by default?

2014-10-02 Thread Matt Rae

Thanks Dave!

A downside to disabling upgrades is that users may have a bad experience if
broken packages get installed and their services don't work. Not sure how
often this would happen.

On Thu, Oct 2, 2014 at 6:19 AM, David Cheney david.che...@canonical.com
wrote:



 On Thu, Oct 2, 2014 at 10: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 updates
 after, so I'm not sure how much the initial upgrade gains.

 Juju is blazing fast! is more exciting than Juju makes sure I'm
 updated initially!

 There is something to be said for having the exact same packages on every
 unit of a service rather than a few units having some versions, then units
 added later getting different versions.


 That happens anyway. Units added later may be built from later releases of
 the cloud image.




 Matt

 On Thu, Oct 2, 2014 at 12:27 AM, Samuel Cozannet 
 samuel.cozan...@canonical.com wrote:

 Why not put our perception to the test?

 Here
 https://docs.google.com/a/canonical.com/spreadsheets/d/1T-8rf_XxXbvCCRRHT69KtRM5k4oJiHyTEuzbENBU0Js/edit#gid=0
 is a spreadsheet where you can compile your variables. The top line
 summarizes the sum of values. The column that gets green is the one we
 should go for [assuming we are representative]

 Sam

 On Thu, Oct 2, 2014 at 7:45 AM, John Meinel j...@arbash-meinel.com
 wrote:

 So there is the question of what is the user experience, and people
 trying out Juju and it seems slow. Though if it is slow, doesn't that mean
 that images are out of date?

 I just bootstrapped a fresh Ubuntu from Amazon's web interface today,
 and I noticed that apt-get upgrade on there installed a new bash to fix the
 newest major security hole. It seems like it is good to at least apply
 security updates, and I'm not sure if it is easy to only install those.

 John
 =:-

 On Thu, Oct 2, 2014 at 7:51 AM, José Antonio Rey j...@ubuntu.com
 wrote:

 I believe that, as Jorge mentioned, most users do value having
 everything up to date by default, specially when they may go directly to
 production environments. Devs may also want to use this switch, as it will
 save time during the deployment for testing the charms they have 
 developed.

 I believe that turning on upgrades as a default would be more valued
 by end-users, but that's just a personal opinion.

 --
 José Antonio Rey
 On Oct 1, 2014 2:34 PM, Jorge O. Castro jo...@ubuntu.com wrote:

 On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu
 kapil.thangav...@canonical.com wrote:
  juju can save minutes per machine (especially against release
 images) if we
  turn off upgrades by default.

 There are some updates coming to how we build cloud images that might
 be relevant to this discussion:

 http://blog.utlemming.org/2014/08/archive-triggered-cloud-image-builds.html

 IMO safer and slower makes sense for most people, those of us who need
 speed for demos/conferences will know about this switch.

 --
 Jorge Castro
 Canonical Ltd.
 http://juju.ubuntu.com/ - Automate your Cloud Infrastructure

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




 --
 Samuel Cozannet
 Cloud, Big Data and IoT Strategy Team
 Strategic Program Manager
 Changing the Future of Cloud
 Ubuntu http://ubuntu.com / Canonical http://canonical.com UK LTD
 samuel.cozan...@canonical.com
 +33 616 702 389


 --
 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: getting rid of all-machines.log

2014-08-14 Thread Matt Rae

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 daemontools can collect
and rotate logs.


On Thu, Aug 14, 2014 at 3:00 AM, Gabriel Samfira 
gsamf...@cloudbasesolutions.com wrote:

 On 14.08.2014 06:20, Ian Booth wrote:
  Just to back up Dave's arguments - all sys admins I know would be a big
 -1 on
  Juju doing it's own log rolling. It's a recipe for lost log files,
 missing data
  etc. It's a mixing of responsibilities that should be handled separately.
 I am unsure how juju rotating its own logs can lead to loss of data. Any
 input on this would be appreciated.
 
  Just on the volume point Dave raised - we do log a lot but that's also an
  orthogonal issue. Even if we logged less we'd still need a rolling
 mechanism.
 
  On 14/08/14 13:13, David Cheney wrote:
  Ian asked me to post my thoughts here.
 
  I am not in favour of applications rolling their own logs, I believe
  that applications should not know anything about their log output,
  they should just dump it all to stdout and another process should take
  care of shuttling the data, logging it, culling it, whatever.
 
  This is summarised here, http://12factor.net/logs
 
  I think our current system with rsyslog is working fine and there is
  no reason to remove it.
 
  The problems with all-machines.log being to large is independent of
  log rolling or any of these other arguments. We simply log too much.
  There would be no request for log rolling it all-machines.log
  contained only useful data.
 
  Dave
 
  On Sat, Aug 9, 2014 at 2:58 AM, Nate Finch nate.fi...@canonical.com
 wrote:
  So, rsyslog rotation works fine on Linux, but we can't do that on
 Windows.
  If we have to do something different for Windows, I'd rather just do
 one
  thing which is cross platform compatible for all our OSes, and not
 have to
  support a different configuration for each OS.  Doing it all
 in-application
  also insulates us from external dependencies... if some future or past
  Ubuntu series (or CentOS) has a different version of rsyslog, it could
  behave differently / require a different configuration, etc.
 
 
 
  On Fri, Aug 8, 2014 at 12:40 PM, David Britton 
 david.brit...@canonical.com
  wrote:
  On Fri, Aug 08, 2014 at 12:03:21PM -0400, Nate Finch wrote:
  [...]
  remote syslog and to the local file log, we wouldn't need to worry
 about
  log rotation of the local log screwing up what gets sent to the
 remote
  Do the standard rsyslog log rotation mechanisms not function well?
 
  On Windows, what about the event log (which has remote
  viewing/aggregation capabilities built in)?
 
  --
  David Britton david.brit...@canonical.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

-- 
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.0-rc3 is here!

Re: Juju 2.0-rc3 is here!

Re: Juju 2.0-rc3 is here!

Re: maas grub issue

Re: Automatic hook retries in Juju 2.0

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

incorrect private address when using manual provider

Re: bootstrap constraints

bootstrap constraints

Re: requirements for

Re: PXE hanging

Re: disabling upgrades on new machines by default?

Re: disabling upgrades on new machines by default?

Re: getting rid of all-machines.log

14 matches

Site Navigation

Mail list logo

Footer information