[Yahoo-eng-team] [Bug 1851552] Re: since ubuntu 18 bionic release and latest, the ubuntu18 cloud image is unable to boot up on openstack instance
I don't believe this is to do with networking-calico, so will mark as Invalid for networking-calico. ** Changed in: networking-calico Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1851552 Title: since ubuntu 18 bionic release and latest, the ubuntu18 cloud image is unable to boot up on openstack instance Status in cloud-init: Invalid Status in networking-calico: Invalid Status in OpenStack Compute (nova): Invalid Status in OpenStack Community Project: New Status in qemu-kvm: New Status in cloud-init package in Ubuntu: Invalid Status in qemu package in Ubuntu: New Bug description: Openstack Queens release which is running on ubuntu 18 LTS Controller and Compute. Tried to boot up the instance via horizon dashboard without success. Nova flow works perfect. When access to console I discovered that the boot process stuck in the middle. [[0;1;31m TIME [0m] Timed out waiting for device dev-vdb.device. [[0;1;33mDEPEND[0m] Dependency failed for /mnt. [[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb. It receives IP but looks like not get configured at time. since ubuntu 18 there is netplan feature managing the network interfaces please advise. more details as follow: https://bugs.launchpad.net/networking-calico/+bug/1851548 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1851552/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1856485] Re: ERROR neutron.manager [-] Plugin 'calico' not found.
Python 3 support was added in Calico v3.15 https://docs.projectcalico.org/release-notes/#v3150 The master networking-calico code now supports Python 3, and no longer Python 2. There is a 'release-v3.15-python2' branch that still supports Python 2, but we are hoping that maintenance of that branch can now be short-lived. ** Changed in: networking-calico Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1856485 Title: ERROR neutron.manager [-] Plugin 'calico' not found. Status in networking-calico: Fix Released Status in neutron: Invalid Status in OpenStack Community Project: New Status in Python Package Index: New Status in Ubuntu Server: New Status in Ubuntu: Confirmed Bug description: Hi, I tried to install Openstack Train with neutron calico driver and getting the following exception: ERROR neutron.manager [-] Plugin ‘calico’ not found. Could someone help me understand if calico driver is ready for Openstack Train or Stein which is running with Python3. If it's still not ready and not working after few years, so what is the developing and QA cycles in calico for Openstack? And what is the solution? Or ETA for solution? Maybe someone can advise for better solution than going with calico to Production and latest Openstack release? Thanks.. see neuton-server log 2019-12-15 22:47:00.418 8031 INFO neutron.common.config [-] Logging enabled! 2019-12-15 22:47:00.418 8031 INFO neutron.common.config [-] /usr/bin/neutron-server version 15.0.0 2019-12-15 22:47:00.419 8031 INFO neutron.common.config [-] Logging enabled! 2019-12-15 22:47:00.419 8031 INFO neutron.common.config [-] /usr/bin/neutron-server version 15.0.0 2019-12-15 22:47:00.793 8031 INFO keyring.backend [-] Loading Gnome 2019-12-15 22:47:00.811 8031 INFO keyring.backend [-] Loading Google 2019-12-15 22:47:00.814 8031 INFO keyring.backend [-] Loading Windows (alt) 2019-12-15 22:47:00.817 8031 INFO keyring.backend [-] Loading file 2019-12-15 22:47:00.819 8031 INFO keyring.backend [-] Loading keyczar 2019-12-15 22:47:00.819 8031 INFO keyring.backend [-] Loading multi 2019-12-15 22:47:00.821 8031 INFO keyring.backend [-] Loading pyfs 2019-12-15 22:47:00.855 8031 INFO neutron.manager [-] Loading core plugin: calico 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime [-] Error loading class by alias: stevedore.exception.NoMatches: No 'neutron.core_plugins' driver found, looking for 'calico' 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime Traceback (most recent call last): 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime File "/usr/lib/python3/dist-packages/neutron_lib/utils/runtime.py", line 114, in load_class_by_alias_or_classname 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime namespace, name, warn_on_missing_entrypoint=False) 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime File "/usr/lib/python3/dist-packages/stevedore/driver.py", line 61, in __init__ 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime warn_on_missing_entrypoint=warn_on_missing_entrypoint 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime File "/usr/lib/python3/dist-packages/stevedore/named.py", line 89, in __init__ 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime self._init_plugins(extensions) 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime File "/usr/lib/python3/dist-packages/stevedore/driver.py", line 113, in _init_plugins 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime (self.namespace, name)) 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime stevedore.exception.NoMatches: No 'neutron.core_plugins' driver found, looking for 'calico' 2019-12-15 22:47:00.856 8031 ERROR neutron_lib.utils.runtime 2019-12-15 22:47:00.857 8031 ERROR neutron_lib.utils.runtime [-] Error loading class by class name: ValueError: Empty module name 2019-12-15 22:47:00.857 8031 ERROR neutron_lib.utils.runtime Traceback (most recent call last): 2019-12-15 22:47:00.857 8031 ERROR neutron_lib.utils.runtime File "/usr/lib/python3/dist-packages/neutron_lib/utils/runtime.py", line 114, in load_class_by_alias_or_classname 2019-12-15 22:47:00.857 8031 ERROR neutron_lib.utils.runtime namespace, name, warn_on_missing_entrypoint=False) 2019-12-15 22:47:00.857 8031 ERROR neutron_lib.utils.runtime File "/usr/lib/python3/dist-packages/stevedore/driver.py", line 61, in __init__ 2019-12-15 22:47:00.857 8031 ERROR neutron_lib.utils.runtime warn_on_missing_entrypoint=warn_on_missing_entrypoint 2019-12-15 22:47:00.857 8031 ERROR neutron_lib.utils.runtime File "/usr/lib/python3/dist-packages/stevedore/named.py", line 89, in __init__ 2019-12-15 22:47:00.857 8031 ERROR neutron_lib.utils.runtime
[Yahoo-eng-team] [Bug 1883730] [NEW] Failed to create a duplicate DefaultSecurityGroup (with Calico plugin)
Public bug reported: With Ussuri I'm hitting this in the neutron server: 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers [req-6160aa90-b69e-451b-9774-07b6d840f41f 088d04a2122548c5acb628348db93c40 11447be9beda4bf78dab27cdb75058e2 - default default] Mechanism driver 'calico' failed in update_port_postcommit: neutron_lib.objects.exceptions.NeutronDbObjectDuplicateEntry: Failed to create a duplicate DefaultSecurityGroup: for attribute(s) ['PRIMARY'] with value(s) 11447be9beda4bf78dab27cdb75058e2 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers Traceback (most recent call last): 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1246, in _execute_context 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers cursor, statement, parameters, context 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers cursor.execute(statement, parameters) 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/pymysql/cursors.py", line 165, in execute 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers result = self._query(query) 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/pymysql/cursors.py", line 321, in _query 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers conn.query(q) 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 860, in query 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers self._affected_rows = self._read_query_result(unbuffered=unbuffered) 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 1061, in _read_query_result 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers result.read() 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 1349, in read 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers first_packet = self.connection._read_packet() 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 1018, in _read_packet 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers packet.check_error() 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 384, in check_error 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers err.raise_mysql_exception(self._data) 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/pymysql/err.py", line 107, in raise_mysql_exception 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers raise errorclass(errno, errval) 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers pymysql.err.IntegrityError: (1062, "Duplicate entry '11447be9beda4bf78dab27cdb75058e2' for key 'PRIMARY'") 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers The above exception was the direct cause of the following exception: 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers Traceback (most recent call last): 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/neutron/objects/base.py", line 867, in create 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers self, self.obj_context, self.modify_fields_to_db(fields)) 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/neutron/objects/db/api.py", line 69, in create_object 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers context.session.add(db_obj) 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3.6/contextlib.py", line 88, in __exit__ 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers next(self.gen) 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line 1064, in _transaction_scope 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers yield resource 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers File "/usr/lib/python3.6/contextlib.py", line 88, in __exit__ 2020-06-15 14:41:44.209 21931 ERROR neutron.plugins.ml2.managers next(self.gen) 2020-06-15
[Yahoo-eng-team] [Bug 1879307] [NEW] Recent stable/rocky change breaks networking-calico's interface driver
Public bug reported: This merge - https://opendev.org/openstack/neutron/commit/a6fb2faaa5d46656db9085ad6bcfc65ded807871 - to the Neutron stable/rocky branch on April 23rd, has broken my team's Neutron plugin, by requiring 3rd party LinuxInterfaceDriver subclasses to take a new 'link_up' argument in their 'plug_new' method. Here's the fix that I've now made: https://github.com/projectcalico /networking- calico/pull/21/commits/bfd54aa841abbba4c591126b0dba083b93c84536 However, this likely affects other out-of-tree plugins as well, and there is still the likelihood of breakage if someone is running Rocky with an affected-but-unfixed plugin, and uses the latest Rocky code. Apparently there will not be another Rocky patch release, so I wonder if it would be better to revert the incompatible change? ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1879307 Title: Recent stable/rocky change breaks networking-calico's interface driver Status in neutron: New Bug description: This merge - https://opendev.org/openstack/neutron/commit/a6fb2faaa5d46656db9085ad6bcfc65ded807871 - to the Neutron stable/rocky branch on April 23rd, has broken my team's Neutron plugin, by requiring 3rd party LinuxInterfaceDriver subclasses to take a new 'link_up' argument in their 'plug_new' method. Here's the fix that I've now made: https://github.com/projectcalico /networking- calico/pull/21/commits/bfd54aa841abbba4c591126b0dba083b93c84536 However, this likely affects other out-of-tree plugins as well, and there is still the likelihood of breakage if someone is running Rocky with an affected-but-unfixed plugin, and uses the latest Rocky code. Apparently there will not be another Rocky patch release, so I wonder if it would be better to revert the incompatible change? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1879307/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1082248] Re: Use uuidutils instead of uuid.uuid4()
I don't see value in this for networking-calico. ** No longer affects: networking-calico -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1082248 Title: Use uuidutils instead of uuid.uuid4() Status in Cinder: Won't Fix Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in Karbor: Fix Released Status in kolla: Fix Released Status in kuryr: Fix Released Status in kuryr-libnetwork: Fix Released Status in Mistral: Fix Released Status in networking-midonet: Fix Released Status in networking-ovn: Fix Released Status in networking-sfc: Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): In Progress Status in osprofiler: Fix Released Status in Sahara: Fix Released Status in senlin: Fix Released Status in OpenStack Object Storage (swift): Won't Fix Status in tacker: In Progress Status in watcher: Fix Released Bug description: Openstack common has a wrapper for generating uuids. We should only use that function when generating uuids for consistency. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1082248/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1664782] [NEW] iptables manager wrongly deletes other agents' rules
Public bug reported:
Calico's Felix agent generates iptables chains that intentionally
include rules that the Neutron iptables_manager code considers to be
duplicates - as revealed by logs like these from the DHCP agent:
2017-02-02 18:50:29.482 3376 WARNING neutron.agent.linux.iptables_manager [-]
Duplicate iptables rule detected. This may indicate a bug in the iptables rule
generation code. Line: -A felix-to-ebf1bc0b-ba -m mark --mark
0x100/0x100 -m comment --comment "Profile accepted packet" -j RETURN
2017-02-02 18:50:29.483 3376 WARNING neutron.agent.linux.iptables_manager [-]
Duplicate iptables rule detected. This may indicate a bug in the iptables rule
generation code. Line: -A felix-to-3d959cf9-36 -m mark --mark
0x100/0x100 -m comment --comment "Profile accepted packet" -j RETURN
2017-02-02 18:50:29.483 3376 WARNING neutron.agent.linux.iptables_manager [-]
Duplicate iptables rule detected. This may indicate a bug in the iptables rule
generation code. Line: -A felix-from-ebf1bc0b-ba -m mark --mark
0x100/0x100 -m comment --comment "Profile accepted packet" -j RETURN
2017-02-02 18:50:29.483 3376 WARNING neutron.agent.linux.iptables_manager [-]
Duplicate iptables rule detected. This may indicate a bug in the iptables rule
generation code. Line: -A felix-from-3d959cf9-36 -m mark --mark
0x100/0x100 -m comment --comment "Profile accepted packet" -j RETURN
IIUC, iptables_manager then reprograms iptables with these 'duplicates'
removed, and thereby breaks Calico's iptables.
** Affects: neutron
Importance: Undecided
Assignee: Neil Jerram (neil-jerram)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1664782
Title:
iptables manager wrongly deletes other agents' rules
Status in neutron:
In Progress
Bug description:
Calico's Felix agent generates iptables chains that intentionally
include rules that the Neutron iptables_manager code considers to be
duplicates - as revealed by logs like these from the DHCP agent:
2017-02-02 18:50:29.482 3376 WARNING neutron.agent.linux.iptables_manager [-]
Duplicate iptables rule detected. This may indicate a bug in the iptables rule
generation code. Line: -A felix-to-ebf1bc0b-ba -m mark --mark
0x100/0x100 -m comment --comment "Profile accepted packet" -j RETURN
2017-02-02 18:50:29.483 3376 WARNING neutron.agent.linux.iptables_manager [-]
Duplicate iptables rule detected. This may indicate a bug in the iptables rule
generation code. Line: -A felix-to-3d959cf9-36 -m mark --mark
0x100/0x100 -m comment --comment "Profile accepted packet" -j RETURN
2017-02-02 18:50:29.483 3376 WARNING neutron.agent.linux.iptables_manager [-]
Duplicate iptables rule detected. This may indicate a bug in the iptables rule
generation code. Line: -A felix-from-ebf1bc0b-ba -m mark --mark
0x100/0x100 -m comment --comment "Profile accepted packet" -j RETURN
2017-02-02 18:50:29.483 3376 WARNING neutron.agent.linux.iptables_manager [-]
Duplicate iptables rule detected. This may indicate a bug in the iptables rule
generation code. Line: -A felix-from-3d959cf9-36 -m mark --mark
0x100/0x100 -m comment --comment "Profile accepted packet" -j RETURN
IIUC, iptables_manager then reprograms iptables with these 'duplicates'
removed, and thereby breaks Calico's iptables.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1664782/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1646802] Re: Calico DHCP agent should use DEFAULT/dns_domain instead of DEFAULT/dhcp_domain
The corresponding Neutron agent code is also still using dhcp_domain in stable/newton and current master. ** Summary changed: - Calico DHCP agent should use DEFAULT/dns_domain instead of DEFAULT/dhcp_domain + DHCP agent should use DEFAULT/dns_domain instead of DEFAULT/dhcp_domain ** Project changed: networking-calico => neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1646802 Title: DHCP agent should use DEFAULT/dns_domain instead of DEFAULT/dhcp_domain Status in neutron: New Bug description: As of Mitaka, DEFAULT/dhcp_domain in neutron.conf seems to be deprecated, the neutron now uses DEFAULT/dns_domain. http://docs.openstack.org/mitaka/config- reference/networking/networking_options_reference.html With Calico DHCP agent, unless we create the deprecated option DEFAULT/dhcp_domain in neutron.conf, the instances resolv.conf contains: domain openstacklocal search openstacklocal ..instead of the desired domain name. It could potentially check for both config options, and make dns_domain tape precedence over dhcp_domain. Cheers, Just To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1646802/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1625209] Re: ipv6 options are being checked for ipv4 subnet
If I understand correctly, this is not an independent bug. Rather, it only arises when changes are made in networking-calico to address another bug (1541490). And the only proposed change for _this_ bug is now also in networking-calico. Therefore it doesn't make sense for this bug to have an independent existence from 1541490, or for any changes for this bug to be separated from proposed changes from 1541490. I will close this bug for networking-calico, and ask that you simply combine all of the networking-calico changes that you think are needed for 1541490. ** Changed in: networking-calico Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1625209 Title: ipv6 options are being checked for ipv4 subnet Status in networking-calico: Invalid Status in neutron: Invalid Bug description: When DHCP agent tries to set fixed_ips parameter for DHCP port (see https://bugs.launchpad.net/networking-calico/+bug/1541490) Neutron checks ipv6_address_mode and ipv6_ra_mode options of subnet that corresponds to the given fixed IP even for IPv4 subnet. And this fails as IPv4 subnet does not have such options (see traceback http://paste.openstack.org/show/580996/). And, of course, you cannot set such flags for IPv4 subnet. I'd expect that such check is performed for IPv6 subnets only. Probably, this situation is possible not only while using non-native DHCP agent. Neutron version: Newton (7f6b5b5d8953159740f74b0a4a5280527f6baa69). Environment: Calico (https://github.com/openstack/networking-calico) over Neutron. Point of failure: https://github.com/openstack/neutron/blob/7f6b5b5d8953159740f74b0a4a5280527f6baa69/neutron/agent/linux/dhcp.py#L1342 Traceback: http://paste.openstack.org/show/580996/ Failure rate: always. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-calico/+bug/1625209/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1506580] [NEW] Request for first release of networking-calico
Public bug reported: Please could you tag and release networking-calico, as it currently stands at: https://git.openstack.org/cgit/openstack/networking-calico neil@nj-ubuntu:~/calico/networking-calico$ git log -1 commit 792f1cf63e63ce4660f837d261e9c2bb66434f7b Author: Neil Jerram <neil.jer...@metaswitch.com> Date: Thu Oct 15 16:07:05 2015 +0100 DevStack plugin doc: mention the bootstrap script Change-Id: I4ea7622d815be946e2dfec445c071d1db8d8bc07 This will be the first ever release of networking-calico, so I guess it will be 1.0.0. ** Affects: networking-calico Importance: Undecided Status: New ** Affects: neutron Importance: Undecided Status: New ** Tags: release-subproject ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1506580 Title: Request for first release of networking-calico Status in networking-calico: New Status in neutron: New Bug description: Please could you tag and release networking-calico, as it currently stands at: https://git.openstack.org/cgit/openstack/networking-calico neil@nj-ubuntu:~/calico/networking-calico$ git log -1 commit 792f1cf63e63ce4660f837d261e9c2bb66434f7b Author: Neil Jerram <neil.jer...@metaswitch.com> Date: Thu Oct 15 16:07:05 2015 +0100 DevStack plugin doc: mention the bootstrap script Change-Id: I4ea7622d815be946e2dfec445c071d1db8d8bc07 This will be the first ever release of networking-calico, so I guess it will be 1.0.0. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-calico/+bug/1506580/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1506054] [NEW] Can't retrieve hypervisor info - Nova Unexpected API error
Public bug reported:
This is a problem I'm seeing in a 3 node DevStack system, stacked today
(14th October 2015). I click on Hypervisors in the System section of
the Horizon UI, to see hypervisor information. Horizon shows an error
box "Unable to retrieve hypervisor information".
/var/log/apache2/horizon_error.log includes this:
2015-10-14 11:04:00.379206 REQ: curl -g -i
'http://calico-vm18:8774/v2.1/3c8d3e6c106c44b6ad37140023b92df8/os-hypervisors/detail'
-X GET -H "Accept: application/json" -H "User-Agent: python-novaclient" -H
"X-Auth-Project-Id: 3c8d3e6c106c44b6ad37140023b92df8" -H "X-Auth-Token:
{SHA1}db34b44f5be5800c12f48ab59251dc8277eb0b0c"
2015-10-14 11:04:00.420325 RESP: [500] {'content-length': '208',
'x-compute-request-id': 'req-6881cfe9-5962-4105-bf46-2d164ef4451c', 'vary':
'X-OpenStack-Nova-API-Version', 'connection': 'keep-alive',
'x-openstack-nova-api-version': '2.1', 'date': 'Wed, 14 Oct 2015 11:04:00 GMT',
'content-type': 'application/json; charset=UTF-8'}
2015-10-14 11:04:00.420358 RESP BODY: {"computeFault": {"message": "Unexpected
API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the
Nova API log if possible.\\n",
"code": 500}}
2015-10-14 11:04:00.420365
2015-10-14 11:04:00.420842 Recoverable error: Unexpected API Error. Please
report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if
possible.
Otherwise the cluster appears to be working; for example I've
successfully launched 10 cirros instances, across the 3 available
compute nodes.
ubuntu@calico-vm18:/opt/stack/nova$ git log -1
commit 1d97b0e7308975cd4a912dda00df8726ba776fe7
Merge: 7200b6a 11e20dd
Author: Jenkins
Date: Wed Oct 14 08:50:59 2015 +
Merge "Ignore errorcode=4 when executing `cryptsetup remove`
command"
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1506054
Title:
Can't retrieve hypervisor info - Nova Unexpected API error
Status in OpenStack Compute (nova):
New
Bug description:
This is a problem I'm seeing in a 3 node DevStack system, stacked
today (14th October 2015). I click on Hypervisors in the System
section of the Horizon UI, to see hypervisor information. Horizon
shows an error box "Unable to retrieve hypervisor information".
/var/log/apache2/horizon_error.log includes this:
2015-10-14 11:04:00.379206 REQ: curl -g -i
'http://calico-vm18:8774/v2.1/3c8d3e6c106c44b6ad37140023b92df8/os-hypervisors/detail'
-X GET -H "Accept: application/json" -H "User-Agent: python-novaclient" -H
"X-Auth-Project-Id: 3c8d3e6c106c44b6ad37140023b92df8" -H "X-Auth-Token:
{SHA1}db34b44f5be5800c12f48ab59251dc8277eb0b0c"
2015-10-14 11:04:00.420325 RESP: [500] {'content-length': '208',
'x-compute-request-id': 'req-6881cfe9-5962-4105-bf46-2d164ef4451c', 'vary':
'X-OpenStack-Nova-API-Version', 'connection': 'keep-alive',
'x-openstack-nova-api-version': '2.1', 'date': 'Wed, 14 Oct 2015 11:04:00 GMT',
'content-type': 'application/json; charset=UTF-8'}
2015-10-14 11:04:00.420358 RESP BODY: {"computeFault": {"message":
"Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/
and attach the Nova API log if possible.\\n", "code": 500}}
2015-10-14 11:04:00.420365
2015-10-14 11:04:00.420842 Recoverable error: Unexpected API Error. Please
report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if
possible.
Otherwise the cluster appears to be working; for example I've
successfully launched 10 cirros instances, across the 3 available
compute nodes.
ubuntu@calico-vm18:/opt/stack/nova$ git log -1
commit 1d97b0e7308975cd4a912dda00df8726ba776fe7
Merge: 7200b6a 11e20dd
Author: Jenkins
Date: Wed Oct 14 08:50:59 2015 +
Merge "Ignore errorcode=4 when executing `cryptsetup remove`
command"
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1506054/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1486649] [NEW] Enhance DHCP agent and IP library for networking-calico interface driver
Public bug reported: networking-calico will very shortly provide an ML2 mechanism driver, DHCP agent interface driver and Devstack plugin to demonstrate the Calico project's idea of using routing - rather than bridging - to provide IP-level connectivity between VMs. The existing Neutron DHCP agent provides a great deal of value in terms of managing Dnsmasq, and of mapping from Neutron data to Dnsmasq config, and networking-calico would very much like to reuse that value, rather than say implementing its own DHCP agent. But, the DHCP agent needs two changes to allow it to provide DHCP service correctly and efficiently in the compute host environment that networking-calico sets up. 1. It needs to invoke Dnsmasq with some different options, because of TAP interfaces in the networking-calico setup not being bridged. 2. It does not need to allocate a unique IP address, from each DHCP- enabled subnet, in each place that it runs. Instead it can use each subnet's gateway IP address. Also in core Neutron there is an IP library module that provides methods for creating certain types of Linux network interfaces. networking- calico's interface driver uses a 'dummy' interface as the placeholder for Dnsmasq's DHCP context information and for the subnet prefix, but the IP library does not yet support the creation of such dummy interfaces. For consistency, therefore, it also makes sense to enhance the IP library so that it supports creation of dummy interfaces. Please note that, although much work remains to define how routed networking is represented in the Neutron API and data model, there are two reasons why it makes sense to proceed with these DHCP agent and IP library changes now. The Neutron-technical reasons is this: whatever API we end up with for routed networking, the DHCP agent code will need to be able to provide DHCP service to unbridged TAP interfaces, just as this bug describes; and the behaviour of the DHCP agent code is not actually driven by API properties, but by a config-defined interface driver. Therefore, when the API for routed networking is decided, the changes covered by this bug will still be correct. The pragmatic / OpenStack community reason is that we (meaning the Calico project) already have several operators interested in and trialling this form of connectivity (even if it means accepting some semantic departures from the current Neutron API), and it will be a major help to both them and us if it is possible, as of the Liberty release, to do this with a vanilla Neutron release. ** Affects: neutron Importance: Undecided Assignee: Neil Jerram (neil-jerram) Status: New ** Tags: rfe ** Changed in: neutron Assignee: (unassigned) = Neil Jerram (neil-jerram) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1486649 Title: Enhance DHCP agent and IP library for networking-calico interface driver Status in neutron: New Bug description: networking-calico will very shortly provide an ML2 mechanism driver, DHCP agent interface driver and Devstack plugin to demonstrate the Calico project's idea of using routing - rather than bridging - to provide IP-level connectivity between VMs. The existing Neutron DHCP agent provides a great deal of value in terms of managing Dnsmasq, and of mapping from Neutron data to Dnsmasq config, and networking-calico would very much like to reuse that value, rather than say implementing its own DHCP agent. But, the DHCP agent needs two changes to allow it to provide DHCP service correctly and efficiently in the compute host environment that networking-calico sets up. 1. It needs to invoke Dnsmasq with some different options, because of TAP interfaces in the networking-calico setup not being bridged. 2. It does not need to allocate a unique IP address, from each DHCP- enabled subnet, in each place that it runs. Instead it can use each subnet's gateway IP address. Also in core Neutron there is an IP library module that provides methods for creating certain types of Linux network interfaces. networking-calico's interface driver uses a 'dummy' interface as the placeholder for Dnsmasq's DHCP context information and for the subnet prefix, but the IP library does not yet support the creation of such dummy interfaces. For consistency, therefore, it also makes sense to enhance the IP library so that it supports creation of dummy interfaces. Please note that, although much work remains to define how routed networking is represented in the Neutron API and data model, there are two reasons why it makes sense to proceed with these DHCP agent and IP library changes now. The Neutron-technical reasons is this: whatever API we end up with for routed networking, the DHCP agent code will need to be able to provide DHCP service to unbridged TAP interfaces, just
[Yahoo-eng-team] [Bug 1472704] [NEW] Support networks that work through routing instead of bridging
Public bug reported: This RFE bug describes and proposes a type of Neutron network in which connectivity between the VMs attached to that network is provided by L3 routing. This type of network provides full (subject to security policy) IP connectivity between VMs in that and other routed networks: v4 and v6, unicast and multicast; but it provides no L2 capability, except as required for this IP connectivity, plus correct operation of the ICMP, ARP and NDP protocols that exist to support IP. Therefore, this kind of network is suitable for VMs that only communicate over IP. Why would anyone want that? Compared to the other kinds of networks that provide connectivity at L2, its arguable benefits are that: - it is conceptually simpler, in that VM data is transported in a uniform way between a VM and its compute host, between compute hosts, and between the data center network and the outside world, without any encapsulation changes anywhere - as a practical consequence, it is easier to debug, using standard tools such as ping, traceroute, wireshark and tcpdump - its scale is not limited in the way that VLAN-based and VXLAN-based networks are, by the practical diameter of the physical underlying L2 network. FYI I started proposing/discussing this as a devref at https://review.openstack.org/#/c/198439/, and lots more detail can be found there about how I think this could work. However, I understand that that is not the correct process, hence in principle starting again here as an RFE bug. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe ** Tags added: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1472704 Title: Support networks that work through routing instead of bridging Status in OpenStack Neutron (virtual network service): New Bug description: This RFE bug describes and proposes a type of Neutron network in which connectivity between the VMs attached to that network is provided by L3 routing. This type of network provides full (subject to security policy) IP connectivity between VMs in that and other routed networks: v4 and v6, unicast and multicast; but it provides no L2 capability, except as required for this IP connectivity, plus correct operation of the ICMP, ARP and NDP protocols that exist to support IP. Therefore, this kind of network is suitable for VMs that only communicate over IP. Why would anyone want that? Compared to the other kinds of networks that provide connectivity at L2, its arguable benefits are that: - it is conceptually simpler, in that VM data is transported in a uniform way between a VM and its compute host, between compute hosts, and between the data center network and the outside world, without any encapsulation changes anywhere - as a practical consequence, it is easier to debug, using standard tools such as ping, traceroute, wireshark and tcpdump - its scale is not limited in the way that VLAN-based and VXLAN-based networks are, by the practical diameter of the physical underlying L2 network. FYI I started proposing/discussing this as a devref at https://review.openstack.org/#/c/198439/, and lots more detail can be found there about how I think this could work. However, I understand that that is not the correct process, hence in principle starting again here as an RFE bug. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1472704/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
