[Bug 1560714] Re: linuxbridge agent configuration file path is wrong for RDO packaging

2016-03-22 Thread David Moreau Simard
Wrong project, meant to use puppet-neutron.

** Changed in: neutron (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1560714

Title:
  linuxbridge agent configuration file path is wrong for RDO packaging

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1560714/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1560714] [NEW] linuxbridge agent configuration file path is wrong for RDO packaging

2016-03-22 Thread David Moreau Simard
Public bug reported:

When trying to setup linuxbridge with puppet-neutron, we see the following 
error:
Error: Could not set 'present' on ensure: No such file or directory - 
/etc/neutron/plugins/linuxbridge/linuxbridge_conf.ini at 
110:/var/tmp/packstack/cfb205b46dae4130be410b551917440b/modules/neutron/manifests/agents/ml2/linuxbridge.pp

Indeed, this path is specified in the provider:
https://github.com/openstack/puppet-neutron/blob/43997b339471ad3e122b589d2d81345bcc27f842/lib/puppet/provider/neutron_agent_linuxbridge/ini_setting.rb

The path provided by the RDO packaging is:
/etc/neutron/plugins/ml2/linuxbridge_agent.ini

The OVS path, in comparison, is correct in:
https://github.com/openstack/puppet-neutron/blob/43997b339471ad3e122b589d2d81345bcc27f842/lib/puppet/provider/neutron_agent_ovs/ini_setting.rb

At /etc/neutron/plugins/ml2/openvswitch_agent.ini

** Affects: neutron (Ubuntu)
 Importance: Undecided
 Status: Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to neutron in Ubuntu.
https://bugs.launchpad.net/bugs/1560714

Title:
  linuxbridge agent configuration file path is wrong for RDO packaging

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1560714/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1560714] [NEW] linuxbridge agent configuration file path is wrong for RDO packaging

2016-03-22 Thread David Moreau Simard
Public bug reported:

When trying to setup linuxbridge with puppet-neutron, we see the following 
error:
Error: Could not set 'present' on ensure: No such file or directory - 
/etc/neutron/plugins/linuxbridge/linuxbridge_conf.ini at 
110:/var/tmp/packstack/cfb205b46dae4130be410b551917440b/modules/neutron/manifests/agents/ml2/linuxbridge.pp

Indeed, this path is specified in the provider:
https://github.com/openstack/puppet-neutron/blob/43997b339471ad3e122b589d2d81345bcc27f842/lib/puppet/provider/neutron_agent_linuxbridge/ini_setting.rb

The path provided by the RDO packaging is:
/etc/neutron/plugins/ml2/linuxbridge_agent.ini

The OVS path, in comparison, is correct in:
https://github.com/openstack/puppet-neutron/blob/43997b339471ad3e122b589d2d81345bcc27f842/lib/puppet/provider/neutron_agent_ovs/ini_setting.rb

At /etc/neutron/plugins/ml2/openvswitch_agent.ini

** Affects: neutron (Ubuntu)
 Importance: Undecided
 Status: Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1560714

Title:
  linuxbridge agent configuration file path is wrong for RDO packaging

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1560714/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1560714] Re: linuxbridge agent configuration file path is wrong for RDO packaging

2016-03-22 Thread David Moreau Simard
Wrong project, meant to use puppet-neutron.

** Changed in: neutron (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to neutron in Ubuntu.
https://bugs.launchpad.net/bugs/1560714

Title:
  linuxbridge agent configuration file path is wrong for RDO packaging

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1560714/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty

2015-04-22 Thread David Moreau Simard
@Bobby

My workaround is applied to the image the instance is spawned with. You
must modify the image, upload that modified image and you will be able
to successfully boot VMs without this issue.

If you do not have access to do that, the only other way I would see
would be to spawn a VM using the image with this problem but pass user-
data to cloud-init to grant you console access, a bit like this:

#cloud-config
users:
  - name: root
lock-passwd: false

chpasswd:
  list: |
root:root
  expire: false

This will allow you to login as root (with password 'root') in the VM
console where you'll be able to either delete the extra eth0 file or
diagnose the problem from there.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1315501

Title:
  cloud-init does not use interfaces.d in trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty

2015-04-22 Thread David Moreau Simard
@Bobby

My workaround is applied to the image the instance is spawned with. You
must modify the image, upload that modified image and you will be able
to successfully boot VMs without this issue.

If you do not have access to do that, the only other way I would see
would be to spawn a VM using the image with this problem but pass user-
data to cloud-init to grant you console access, a bit like this:

#cloud-config
users:
  - name: root
lock-passwd: false

chpasswd:
  list: |
root:root
  expire: false

This will allow you to login as root (with password 'root') in the VM
console where you'll be able to either delete the extra eth0 file or
diagnose the problem from there.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1315501

Title:
  cloud-init does not use interfaces.d in trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty

2015-04-21 Thread David Moreau Simard
Lots of people asking for workarounds, I figured I would post mine - it
involves deleting the eth0 file from /etc/network/interfaces.d prior to
using the image. So it goes a bit like this:

# Install qemu-utils
apt-get install qemu-utils

# Mount the Ubuntu cloud image
modprobe nbd max_part=63
qemu-nbd -c /dev/nbd0 trusty-server-cloudimg-amd64-disk1.img
mount /dev/nbd0p1 /mnt/
rm /mnt/etc/network/interaces.d/eth0
umount /mnt

# Upload and use the edited image

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1315501

Title:
  cloud-init does not use interfaces.d in trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty

2015-04-21 Thread David Moreau Simard
Lots of people asking for workarounds, I figured I would post mine - it
involves deleting the eth0 file from /etc/network/interfaces.d prior to
using the image. So it goes a bit like this:

# Install qemu-utils
apt-get install qemu-utils

# Mount the Ubuntu cloud image
modprobe nbd max_part=63
qemu-nbd -c /dev/nbd0 trusty-server-cloudimg-amd64-disk1.img
mount /dev/nbd0p1 /mnt/
rm /mnt/etc/network/interaces.d/eth0
umount /mnt

# Upload and use the edited image

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1315501

Title:
  cloud-init does not use interfaces.d in trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1434684] Re: Pacemaker is not started and stopped automatically with Corosync

2015-03-20 Thread David Moreau Simard
** Description changed:

  In Ubuntu 12.04 with:
  # dpkg -l |egrep pacemaker|corosync
  ii  corosync 1.4.2-2ubuntu0.2  
Standards-based cluster framework (daemon and modules)
  ii  pacemaker1.1.6-2ubuntu3.3  HA 
cluster resource manager
  
  When I start corosync, it'll start the pacemaker resources:
  # ps aux |egrep (heartbeat|corosync)
  root 27043  0.2  0.0 511172  3756 ?Ssl  19:43   0:00 
/usr/sbin/corosync
  root 27051  0.0  0.0  84716  3124 ?S19:43   0:00 
/usr/lib/heartbeat/stonithd
  109  27052  0.1  0.1  88768  5856 ?S19:43   0:00 
/usr/lib/heartbeat/cib
  root 27053  0.1  0.0  97432  3256 ?S19:43   0:00 
/usr/lib/heartbeat/lrmd
  109  27054  0.0  0.0  84756  3364 ?S19:43   0:00 
/usr/lib/heartbeat/attrd
  109  27055  0.0  0.0  79040  2872 ?S19:43   0:00 
/usr/lib/heartbeat/pengine
  109  27056  0.0  0.0  95476  4028 ?S19:43   0:00 
/usr/lib/heartbeat/crmd
  
  When I stop corosync, it'll stop them as well.
  
  In Ubuntu 14.04 with:
  # dpkg -l |egrep pacemaker|corosync
  ii  corosync2.3.3-1ubuntu1   
amd64Standards-based cluster framework (daemon and modules)
  ii  crmsh   1.2.5+hg1034-1ubuntu4all  
CRM shell for the pacemaker cluster manager
  ii  libcorosync-common4 2.3.3-1ubuntu1   
amd64Standards-based cluster framework, common library
  ii  pacemaker   1.1.10+git20130802-1ubuntu2.3
amd64HA cluster resource manager
  ii  pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.3
amd64Command line interface utilities for Pacemaker
  
  When I start corosync, it will NOT start the pacemaker resources. I need
  to start pacemaker manually (service pacemaker start or
  /etc/init.d/pacemaker start).
  
  This results in nothing working until I figured that out. Yielding errors 
such as:
  ---
  # crm status
  Could not establish cib_ro connection: Connection refused (111)
  ERROR: crm_mon exited with code 107 and said: Connection to cluster failed: 
Transport endpoint is not connected
  ---
  # crm_mon
  Attempting connection to the cluster...Could not establish cib_ro connection: 
Connection refused (111)
  ---
  
+ In my testing, both the precise and trusty releases had Pacemaker in the 
service.d directory as such:
+ ---
+ service {
+   name: pacemaker
+   ver:  0
+ }
+ ---
+ 
  Is this a bug or is it expected that Pacemaker is no longer started and
  stopped by corosync ?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1434684

Title:
  Pacemaker is not started and stopped automatically with Corosync

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1434684/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1434684] Re: Pacemaker is not started and stopped automatically with Corosync

2015-03-20 Thread David Moreau Simard
** Description changed:

  In Ubuntu 12.04 with:
  # dpkg -l |egrep pacemaker|corosync
  ii  corosync 1.4.2-2ubuntu0.2  
Standards-based cluster framework (daemon and modules)
  ii  pacemaker1.1.6-2ubuntu3.3  HA 
cluster resource manager
  
  When I start corosync, it'll start the pacemaker resources:
  # ps aux |egrep (heartbeat|corosync)
  root 27043  0.2  0.0 511172  3756 ?Ssl  19:43   0:00 
/usr/sbin/corosync
  root 27051  0.0  0.0  84716  3124 ?S19:43   0:00 
/usr/lib/heartbeat/stonithd
  109  27052  0.1  0.1  88768  5856 ?S19:43   0:00 
/usr/lib/heartbeat/cib
  root 27053  0.1  0.0  97432  3256 ?S19:43   0:00 
/usr/lib/heartbeat/lrmd
  109  27054  0.0  0.0  84756  3364 ?S19:43   0:00 
/usr/lib/heartbeat/attrd
  109  27055  0.0  0.0  79040  2872 ?S19:43   0:00 
/usr/lib/heartbeat/pengine
  109  27056  0.0  0.0  95476  4028 ?S19:43   0:00 
/usr/lib/heartbeat/crmd
  
  When I stop corosync, it'll stop them as well.
  
  In Ubuntu 14.04 with:
  # dpkg -l |egrep pacemaker|corosync
  ii  corosync2.3.3-1ubuntu1   
amd64Standards-based cluster framework (daemon and modules)
  ii  crmsh   1.2.5+hg1034-1ubuntu4all  
CRM shell for the pacemaker cluster manager
  ii  libcorosync-common4 2.3.3-1ubuntu1   
amd64Standards-based cluster framework, common library
  ii  pacemaker   1.1.10+git20130802-1ubuntu2.3
amd64HA cluster resource manager
  ii  pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.3
amd64Command line interface utilities for Pacemaker
  
  When I start corosync, it will NOT start the pacemaker resources. I need
  to start pacemaker manually (service pacemaker start or
  /etc/init.d/pacemaker start).
  
  This results in nothing working until I figured that out. Yielding errors 
such as:
  ---
  # crm status
  Could not establish cib_ro connection: Connection refused (111)
  ERROR: crm_mon exited with code 107 and said: Connection to cluster failed: 
Transport endpoint is not connected
  ---
  # crm_mon
  Attempting connection to the cluster...Could not establish cib_ro connection: 
Connection refused (111)
  ---
  
+ In my testing, both the precise and trusty releases had Pacemaker in the 
service.d directory as such:
+ ---
+ service {
+   name: pacemaker
+   ver:  0
+ }
+ ---
+ 
  Is this a bug or is it expected that Pacemaker is no longer started and
  stopped by corosync ?

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to corosync in Ubuntu.
https://bugs.launchpad.net/bugs/1434684

Title:
  Pacemaker is not started and stopped automatically with Corosync

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1434684/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1434684] [NEW] Pacemaker is not started and stopped automatically with Corosync

2015-03-20 Thread David Moreau Simard
Public bug reported:

In Ubuntu 12.04 with:
# dpkg -l |egrep pacemaker|corosync
ii  corosync 1.4.2-2ubuntu0.2  
Standards-based cluster framework (daemon and modules)
ii  pacemaker1.1.6-2ubuntu3.3  HA 
cluster resource manager

When I start corosync, it'll start the pacemaker resources:
# ps aux |egrep (heartbeat|corosync)
root 27043  0.2  0.0 511172  3756 ?Ssl  19:43   0:00 
/usr/sbin/corosync
root 27051  0.0  0.0  84716  3124 ?S19:43   0:00 
/usr/lib/heartbeat/stonithd
109  27052  0.1  0.1  88768  5856 ?S19:43   0:00 
/usr/lib/heartbeat/cib
root 27053  0.1  0.0  97432  3256 ?S19:43   0:00 
/usr/lib/heartbeat/lrmd
109  27054  0.0  0.0  84756  3364 ?S19:43   0:00 
/usr/lib/heartbeat/attrd
109  27055  0.0  0.0  79040  2872 ?S19:43   0:00 
/usr/lib/heartbeat/pengine
109  27056  0.0  0.0  95476  4028 ?S19:43   0:00 
/usr/lib/heartbeat/crmd

When I stop corosync, it'll stop them as well.

In Ubuntu 14.04 with:
# dpkg -l |egrep pacemaker|corosync
ii  corosync2.3.3-1ubuntu1   amd64  
  Standards-based cluster framework (daemon and modules)
ii  crmsh   1.2.5+hg1034-1ubuntu4all
  CRM shell for the pacemaker cluster manager
ii  libcorosync-common4 2.3.3-1ubuntu1   amd64  
  Standards-based cluster framework, common library
ii  pacemaker   1.1.10+git20130802-1ubuntu2.3amd64  
  HA cluster resource manager
ii  pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.3amd64  
  Command line interface utilities for Pacemaker

When I start corosync, it will NOT start the pacemaker resources. I need
to start pacemaker manually (service pacemaker start or
/etc/init.d/pacemaker start).

This results in nothing working until I figured that out. Yielding errors such 
as:
---
# crm status
Could not establish cib_ro connection: Connection refused (111)
ERROR: crm_mon exited with code 107 and said: Connection to cluster failed: 
Transport endpoint is not connected
---
# crm_mon
Attempting connection to the cluster...Could not establish cib_ro connection: 
Connection refused (111)
---

Is this a bug or is it expected that Pacemaker is no longer started and
stopped by corosync ?

** Affects: corosync (Ubuntu)
 Importance: Undecided
 Status: New

** Summary changed:

- Pacemaker is not started automatically with Corosync
+ Pacemaker is not started and stopped automatically with Corosync

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to corosync in Ubuntu.
https://bugs.launchpad.net/bugs/1434684

Title:
  Pacemaker is not started and stopped automatically with Corosync

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1434684/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1434684] [NEW] Pacemaker is not started and stopped automatically with Corosync

2015-03-20 Thread David Moreau Simard
Public bug reported:

In Ubuntu 12.04 with:
# dpkg -l |egrep pacemaker|corosync
ii  corosync 1.4.2-2ubuntu0.2  
Standards-based cluster framework (daemon and modules)
ii  pacemaker1.1.6-2ubuntu3.3  HA 
cluster resource manager

When I start corosync, it'll start the pacemaker resources:
# ps aux |egrep (heartbeat|corosync)
root 27043  0.2  0.0 511172  3756 ?Ssl  19:43   0:00 
/usr/sbin/corosync
root 27051  0.0  0.0  84716  3124 ?S19:43   0:00 
/usr/lib/heartbeat/stonithd
109  27052  0.1  0.1  88768  5856 ?S19:43   0:00 
/usr/lib/heartbeat/cib
root 27053  0.1  0.0  97432  3256 ?S19:43   0:00 
/usr/lib/heartbeat/lrmd
109  27054  0.0  0.0  84756  3364 ?S19:43   0:00 
/usr/lib/heartbeat/attrd
109  27055  0.0  0.0  79040  2872 ?S19:43   0:00 
/usr/lib/heartbeat/pengine
109  27056  0.0  0.0  95476  4028 ?S19:43   0:00 
/usr/lib/heartbeat/crmd

When I stop corosync, it'll stop them as well.

In Ubuntu 14.04 with:
# dpkg -l |egrep pacemaker|corosync
ii  corosync2.3.3-1ubuntu1   amd64  
  Standards-based cluster framework (daemon and modules)
ii  crmsh   1.2.5+hg1034-1ubuntu4all
  CRM shell for the pacemaker cluster manager
ii  libcorosync-common4 2.3.3-1ubuntu1   amd64  
  Standards-based cluster framework, common library
ii  pacemaker   1.1.10+git20130802-1ubuntu2.3amd64  
  HA cluster resource manager
ii  pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.3amd64  
  Command line interface utilities for Pacemaker

When I start corosync, it will NOT start the pacemaker resources. I need
to start pacemaker manually (service pacemaker start or
/etc/init.d/pacemaker start).

This results in nothing working until I figured that out. Yielding errors such 
as:
---
# crm status
Could not establish cib_ro connection: Connection refused (111)
ERROR: crm_mon exited with code 107 and said: Connection to cluster failed: 
Transport endpoint is not connected
---
# crm_mon
Attempting connection to the cluster...Could not establish cib_ro connection: 
Connection refused (111)
---

Is this a bug or is it expected that Pacemaker is no longer started and
stopped by corosync ?

** Affects: corosync (Ubuntu)
 Importance: Undecided
 Status: New

** Summary changed:

- Pacemaker is not started automatically with Corosync
+ Pacemaker is not started and stopped automatically with Corosync

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1434684

Title:
  Pacemaker is not started and stopped automatically with Corosync

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1434684/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1412979] [NEW] iptables-persistent fails to save if ipv6 is disabled

2015-01-20 Thread David Moreau Simard
Public bug reported:

This bug was fixed upstream by Debian: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=651903

Essentially, service iptables-persistent save will always attempt to save 
both ipv4 and ipv6 rules.
If ipv6 is disabled, aka:
  - net.ipv6.conf.all.disable_ipv6 = 1
  - net.ipv6.conf.default.disable_ipv6 = 1
  - net.ipv6.conf.lo.disable_ipv6 = 1

iptables-persistent will fail with the following message:
# service iptables-persistent save
 * Saving rules...  


   *  IPv4...   


 *  IPv6... 



  ip6tables-save v1.4.12: Cannot initialize: Address family not 
supported by protocol

Hitting this bug under Ubuntu 12.04 currently with the latest version of these 
packages:
ii  iptables 1.4.12-1ubuntu5   
administration tools for packet filtering and NAT
ii  iptables-persistent  0.5.3ubuntu2  
boot-time loader for iptables rules

It doesn't look like I'm able to reproduce this on Ubuntu 14.04 with the latest 
version of these packages:
ii  iptables1.4.21-1ubuntu1  amd64  
  administration tools for packet filtering and NAT
ii  iptables-persistent 0.5.7all
  boot-time loader for iptables rules

Can we backport the necessary patch to precise ?

** Affects: iptables-persistent (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1412979

Title:
  iptables-persistent fails to save if ipv6 is disabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables-persistent/+bug/1412979/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1367791] [NEW] check_ntp_time returns unknown with peer reporting stratum 0

2014-09-10 Thread David Moreau Simard
Public bug reported:

Lots of reference reading:
- http://serverfault.com/questions/625027/nagios-check-ntp-time-offset-unknown
- http://serverfault.com/questions/269701/nagios-ntp-discarding-peer
- http://sourceforge.net/p/nagiosplug/mailman/message/24582375/

Using this check on more than a hundred servers configured similarly, the check 
fails like so on just a few nodes (5):
sending request to peer 0
response from peer 0: offset -0.08336162567
sending request to peer 0
response from peer 0: offset -0.08346772194
sending request to peer 0
response from peer 0: offset -0.08303678036
sending request to peer 0
response from peer 0: offset -0.08342885971
discarding peer 0: stratum=0
overall average offset: 0
NTP CRITICAL: Offset unknown|

=

##
# Monitoring node
## 
# /usr/lib/nagios/plugins/check_ntp_time -V
check_ntp_time v1.5 (nagios-plugins 1.5)

# dpkg -l |grep nagios-plugins
ii  nagios-plugins   1.5-3ubuntu1  all  
Plugins for nagios compatible monitoring systems (metapackage)
ii  nagios-plugins-basic 1.5-3ubuntu1  amd64
Plugins for nagios compatible monitoring systems
ii  nagios-plugins-common1.5-3ubuntu1  amd64
Common files for plugins for nagios compatible monitoring
ii  nagios-plugins-standard  1.5-3ubuntu1  amd64
Plugins for nagios compatible monitoring systems

# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS

# uname -a
Linux node01 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux

# ntpq -c rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version=ntpd 4.2.6p5@1.2349-o Wed Oct  9 19:08:06 UTC 2013 (1),
processor=x86_64, system=Linux/3.13.0-24-generic, leap=00, stratum=3,
precision=-21, rootdelay=92.244, rootdisp=76.080, refid=91.189.94.4,
reftime=d7bae397.935fbf98  Wed, Sep 10 2014 10:49:59.575,
clock=d7bae3ec.1dd1b78d  Wed, Sep 10 2014 10:51:24.116, peer=29730, tc=7,
mintc=3, offset=0.334, frequency=-10.289, sys_jitter=0.508,
clk_jitter=0.803, clk_wander=0.047

# On the ntp peer client (monitored server):
# ntpq -c rv
associd=0 status=c012 leap_alarm, sync_unspec, 1 event, freq_set,
version=ntpd 4.2.6p3@1.2290-o Tue Jun  5 20:12:08 UTC 2012 (1),
processor=x86_64, system=Linux/3.5.0-23-generic, leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdisp=27.810, refid=INIT,
reftime=.  Mon, Jan  1 1900  0:00:00.000,
clock=d7bae3d4.d1ed6996  Wed, Sep 10 2014 14:51:00.820, peer=0, tc=3,
mintc=3, offset=0.000, frequency=-0.600, sys_jitter=0.000,
clk_jitter=0.002, clk_wander=0.000

** Affects: nagios-plugins (Ubuntu)
 Importance: Undecided
 Status: New

** Summary changed:

- check_ntp_time fails when peer reports stratum 0
+ check_ntp_time returns unknown with peer reporting stratum 0

** Description changed:

  Lots of reference reading:
  - http://serverfault.com/questions/625027/nagios-check-ntp-time-offset-unknown
  - http://serverfault.com/questions/269701/nagios-ntp-discarding-peer
  - http://sourceforge.net/p/nagiosplug/mailman/message/24582375/
  
  Using this check on more than a hundred servers configured similarly, the 
check fails like so on just a few nodes (5):
  sending request to peer 0
  response from peer 0: offset -0.08336162567
  sending request to peer 0
  response from peer 0: offset -0.08346772194
  sending request to peer 0
  response from peer 0: offset -0.08303678036
  sending request to peer 0
  response from peer 0: offset -0.08342885971
  discarding peer 0: stratum=0
  overall average offset: 0
  NTP CRITICAL: Offset unknown|
  
  =
  
+ ##
+ # Monitoring node
+ ## 
  # /usr/lib/nagios/plugins/check_ntp_time -V
  check_ntp_time v1.5 (nagios-plugins 1.5)
  
  # dpkg -l |grep nagios-plugins
  ii  nagios-plugins   1.5-3ubuntu1  all
  Plugins for nagios compatible monitoring systems (metapackage)
  ii  nagios-plugins-basic 1.5-3ubuntu1  amd64  
  Plugins for nagios compatible monitoring systems
  ii  nagios-plugins-common1.5-3ubuntu1  amd64  
  Common files for plugins for nagios compatible monitoring
  ii  nagios-plugins-standard  1.5-3ubuntu1  amd64  
  Plugins for nagios compatible monitoring systems
  
  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=14.04
  DISTRIB_CODENAME=trusty
  DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS
  
  # uname -a
  Linux node01 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux
+ 
+ # ntpq -c rv
+ associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
+ version=ntpd 4.2.6p5@1.2349-o Wed Oct  9 19:08:06 UTC 2013 (1),
+ processor=x86_64, system=Linux/3.13.0-24-generic, leap=00, stratum=3,
+ precision=-21, 

[Bug 1367791] [NEW] check_ntp_time returns unknown with peer reporting stratum 0

2014-09-10 Thread David Moreau Simard
Public bug reported:

Lots of reference reading:
- http://serverfault.com/questions/625027/nagios-check-ntp-time-offset-unknown
- http://serverfault.com/questions/269701/nagios-ntp-discarding-peer
- http://sourceforge.net/p/nagiosplug/mailman/message/24582375/

Using this check on more than a hundred servers configured similarly, the check 
fails like so on just a few nodes (5):
sending request to peer 0
response from peer 0: offset -0.08336162567
sending request to peer 0
response from peer 0: offset -0.08346772194
sending request to peer 0
response from peer 0: offset -0.08303678036
sending request to peer 0
response from peer 0: offset -0.08342885971
discarding peer 0: stratum=0
overall average offset: 0
NTP CRITICAL: Offset unknown|

=

##
# Monitoring node
## 
# /usr/lib/nagios/plugins/check_ntp_time -V
check_ntp_time v1.5 (nagios-plugins 1.5)

# dpkg -l |grep nagios-plugins
ii  nagios-plugins   1.5-3ubuntu1  all  
Plugins for nagios compatible monitoring systems (metapackage)
ii  nagios-plugins-basic 1.5-3ubuntu1  amd64
Plugins for nagios compatible monitoring systems
ii  nagios-plugins-common1.5-3ubuntu1  amd64
Common files for plugins for nagios compatible monitoring
ii  nagios-plugins-standard  1.5-3ubuntu1  amd64
Plugins for nagios compatible monitoring systems

# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS

# uname -a
Linux node01 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux

# ntpq -c rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version=ntpd 4.2.6p5@1.2349-o Wed Oct  9 19:08:06 UTC 2013 (1),
processor=x86_64, system=Linux/3.13.0-24-generic, leap=00, stratum=3,
precision=-21, rootdelay=92.244, rootdisp=76.080, refid=91.189.94.4,
reftime=d7bae397.935fbf98  Wed, Sep 10 2014 10:49:59.575,
clock=d7bae3ec.1dd1b78d  Wed, Sep 10 2014 10:51:24.116, peer=29730, tc=7,
mintc=3, offset=0.334, frequency=-10.289, sys_jitter=0.508,
clk_jitter=0.803, clk_wander=0.047

# On the ntp peer client (monitored server):
# ntpq -c rv
associd=0 status=c012 leap_alarm, sync_unspec, 1 event, freq_set,
version=ntpd 4.2.6p3@1.2290-o Tue Jun  5 20:12:08 UTC 2012 (1),
processor=x86_64, system=Linux/3.5.0-23-generic, leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdisp=27.810, refid=INIT,
reftime=.  Mon, Jan  1 1900  0:00:00.000,
clock=d7bae3d4.d1ed6996  Wed, Sep 10 2014 14:51:00.820, peer=0, tc=3,
mintc=3, offset=0.000, frequency=-0.600, sys_jitter=0.000,
clk_jitter=0.002, clk_wander=0.000

** Affects: nagios-plugins (Ubuntu)
 Importance: Undecided
 Status: New

** Summary changed:

- check_ntp_time fails when peer reports stratum 0
+ check_ntp_time returns unknown with peer reporting stratum 0

** Description changed:

  Lots of reference reading:
  - http://serverfault.com/questions/625027/nagios-check-ntp-time-offset-unknown
  - http://serverfault.com/questions/269701/nagios-ntp-discarding-peer
  - http://sourceforge.net/p/nagiosplug/mailman/message/24582375/
  
  Using this check on more than a hundred servers configured similarly, the 
check fails like so on just a few nodes (5):
  sending request to peer 0
  response from peer 0: offset -0.08336162567
  sending request to peer 0
  response from peer 0: offset -0.08346772194
  sending request to peer 0
  response from peer 0: offset -0.08303678036
  sending request to peer 0
  response from peer 0: offset -0.08342885971
  discarding peer 0: stratum=0
  overall average offset: 0
  NTP CRITICAL: Offset unknown|
  
  =
  
+ ##
+ # Monitoring node
+ ## 
  # /usr/lib/nagios/plugins/check_ntp_time -V
  check_ntp_time v1.5 (nagios-plugins 1.5)
  
  # dpkg -l |grep nagios-plugins
  ii  nagios-plugins   1.5-3ubuntu1  all
  Plugins for nagios compatible monitoring systems (metapackage)
  ii  nagios-plugins-basic 1.5-3ubuntu1  amd64  
  Plugins for nagios compatible monitoring systems
  ii  nagios-plugins-common1.5-3ubuntu1  amd64  
  Common files for plugins for nagios compatible monitoring
  ii  nagios-plugins-standard  1.5-3ubuntu1  amd64  
  Plugins for nagios compatible monitoring systems
  
  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=14.04
  DISTRIB_CODENAME=trusty
  DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS
  
  # uname -a
  Linux node01 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux
+ 
+ # ntpq -c rv
+ associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
+ version=ntpd 4.2.6p5@1.2349-o Wed Oct  9 19:08:06 UTC 2013 (1),
+ processor=x86_64, system=Linux/3.13.0-24-generic, leap=00, stratum=3,
+ precision=-21, 

[Bug 1324557] [NEW] swift-recon --objmd5 is no longer valid

2014-05-29 Thread David Moreau Simard
Public bug reported:

Using package versions:
ii  python-swift1.13.1-0ubuntu1~cloud0
distributed virtual object store - Python libraries
ii  python-swiftclient  1:2.0.3-0ubuntu1~cloud0   Client 
library for Openstack Swift API.
ii  swift   1.13.1-0ubuntu1~cloud0
distributed virtual object store - common files
ii  swift-proxy 1.13.1-0ubuntu1~cloud0
distributed virtual object store - proxy server

check_swift_object_servers uses swift-recon --objmd5. This command no
longer exists, it is now swift-recon --md5.

** Affects: nagios-plugins-openstack (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1324557

Title:
  swift-recon --objmd5 is no longer valid

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nagios-plugins-openstack/+bug/1324557/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1317381] Re: [SRU] swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in the repository when used with ceilometer

2014-05-19 Thread David Moreau Simard
Scott / James:

What is the general process for the cloud archive ? Are the fixes
backported/cherry-picked from the current stable branch (trusty) once
they make it out of proposed ?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317381

Title:
  [SRU] swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is
  present in the repository when used with ceilometer

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1317381/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

2014-05-14 Thread David Moreau Simard
** Also affects: cloud-archive
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to swift in Ubuntu.
https://bugs.launchpad.net/bugs/1317147

Title:
  Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1317381] Re: Swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in the repository

2014-05-14 Thread David Moreau Simard
This is linked to another dependency problem in bug
https://bugs.launchpad.net/ubuntu/+source/swift/+bug/1317147.

** Also affects: cloud-archive
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to swift in Ubuntu.
https://bugs.launchpad.net/bugs/1317381

Title:
  Swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in
  the repository

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1317381/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

2014-05-14 Thread David Moreau Simard
See: https://ask.openstack.org/en/question/27951/pecan-version-for-
ceilometer-in-icehouse-swift-proxy/

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317147

Title:
  Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

2014-05-14 Thread David Moreau Simard
I'm also affected, using the cloud-archive repository for Icehouse on
Ubuntu precise.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317147

Title:
  Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

2014-05-14 Thread David Moreau Simard
** Also affects: cloud-archive
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317147

Title:
  Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

2014-05-14 Thread David Moreau Simard
Once the pecan dependency is manually fixed, it also complains about
another incorrect version:

pkg_resources.VersionConflict: (happybase 0.7 (/usr/lib/python2.7/dist-
packages), Requirement.parse('happybase=0.5,!=0.7'))

This would need to be fixed as well.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317147

Title:
  Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1317381] Re: Swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in the repository

2014-05-14 Thread David Moreau Simard
This is linked to another dependency problem in bug
https://bugs.launchpad.net/ubuntu/+source/swift/+bug/1317147.

** Also affects: cloud-archive
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317381

Title:
  Swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in
  the repository

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1317381/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

2014-05-14 Thread David Moreau Simard
Oh, sorry for the spam. The happybase bug is reported in another bug:
https://bugs.launchpad.net/ubuntu/+source/swift/+bug/1317381

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317147

Title:
  Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty

2014-05-13 Thread David Moreau Simard
Hi Scott,

You're correct, we use config drive in our implementation 
(using_config_drive=True for nova-compute).
The template used by nova is located here: 
https://github.com/openstack/nova/blob/master/nova/virt/interfaces.template

I also see your point that Nova could also implement a fix for this. I
will check with them and refer to this bug.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1315501

Title:
  cloud-init does not use interfaces.d in trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty

2014-05-13 Thread David Moreau Simard
Adding the openstack nova bug for cross reference:
https://bugs.launchpad.net/nova/+bug/1319117

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1315501

Title:
  cloud-init does not use interfaces.d in trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty

2014-05-13 Thread David Moreau Simard
Hi Scott,

You're correct, we use config drive in our implementation 
(using_config_drive=True for nova-compute).
The template used by nova is located here: 
https://github.com/openstack/nova/blob/master/nova/virt/interfaces.template

I also see your point that Nova could also implement a fix for this. I
will check with them and refer to this bug.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1315501

Title:
  cloud-init does not use interfaces.d in trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty

2014-05-13 Thread David Moreau Simard
Adding the openstack nova bug for cross reference:
https://bugs.launchpad.net/nova/+bug/1319117

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1315501

Title:
  cloud-init does not use interfaces.d in trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs