[Yahoo-eng-team] [Bug 1900934] [NEW] [RFE][DHCP][OVS] flow based DHCP
Public bug reported: Add a new ovs agent extension to support fully distributed DHCP for VMs in compute nodes, especially for large scale cloud. We had some disscussions during Shanghai PTG: https://etherpad.opendev.org/p/Shanghai-Neutron-Planning-restored http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010702.html https://github.com/gotostack/shanghai_ptg/blob/master/shanghai_neutron_ptg_topics_liuyulong.pdf ** Affects: neutron Importance: Undecided Status: New ** Attachment added: "dhcp_ovs.png" https://bugs.launchpad.net/bugs/1900934/+attachment/5425306/+files/dhcp_ovs.png -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1900934 Title: [RFE][DHCP][OVS] flow based DHCP Status in neutron: New Bug description: Add a new ovs agent extension to support fully distributed DHCP for VMs in compute nodes, especially for large scale cloud. We had some disscussions during Shanghai PTG: https://etherpad.opendev.org/p/Shanghai-Neutron-Planning-restored http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010702.html https://github.com/gotostack/shanghai_ptg/blob/master/shanghai_neutron_ptg_topics_liuyulong.pdf To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1900934/+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 1900863] [NEW] Unable to override color of even lines in horizon tables
Public bug reported: I'm trying to define a black theme for the Horizon dashboard and I managed to do most of the work by overriding scss variables in my theme. However I can't change the even lines of the instance table. They remain black whatever I put in the variable $table-bg-even To reproduce : 1) Create a theme and try to override the variable $table-bg-even with #ff5050 2) Deploy the theme 3) Open the instances panel with at least two VMs 4) The even lines remain white instead of red Possible root cause : I think that this is caused by the missing "!default" next to $table-bg- even in the file /static/dashboard/scss/_variables.scss ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1900863 Title: Unable to override color of even lines in horizon tables Status in OpenStack Dashboard (Horizon): New Bug description: I'm trying to define a black theme for the Horizon dashboard and I managed to do most of the work by overriding scss variables in my theme. However I can't change the even lines of the instance table. They remain black whatever I put in the variable $table-bg-even To reproduce : 1) Create a theme and try to override the variable $table-bg-even with #ff5050 2) Deploy the theme 3) Open the instances panel with at least two VMs 4) The even lines remain white instead of red Possible root cause : I think that this is caused by the missing "!default" next to $table- bg-even in the file /static/dashboard/scss/_variables.scss To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1900863/+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 1881771] Re: neutron-ipset-cleanup fails with Traceback: Unhandled error: oslo_config.cfg.NoSuchOptError: no such option AGENT in group [DEFAULT]
This was released to Focal via a stable point release of Neutron ** Changed in: neutron (Ubuntu Focal) Status: Triaged => 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/1881771 Title: neutron-ipset-cleanup fails with Traceback: Unhandled error: oslo_config.cfg.NoSuchOptError: no such option AGENT in group [DEFAULT] Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Focal: Fix Released Bug description: # /usr/bin/neutron-ipset-cleanup --debug --config-file /etc/neutron/neutron.conf 2020-06-02 14:36:08.891 124358 INFO neutron.common.config [-] Logging enabled! 2020-06-02 14:36:08.892 124358 INFO neutron.common.config [-] /usr/bin/neutron-ipset-cleanup version 16.0.0.0b3 2020-06-02 14:36:08.892 124358 INFO neutron.cmd.ipset_cleanup [-] Destroying IPsets with prefix: N 2020-06-02 14:36:08.892 124358 CRITICAL neutron [-] Unhandled error: oslo_config.cfg.NoSuchOptError: no such option AGENT in group [DEFAULT] 2020-06-02 14:36:08.892 124358 ERROR neutron Traceback (most recent call last): 2020-06-02 14:36:08.892 124358 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 2197, in __getattr__ 2020-06-02 14:36:08.892 124358 ERROR neutron return self._get(name) 2020-06-02 14:36:08.892 124358 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 2631, in _get 2020-06-02 14:36:08.892 124358 ERROR neutron value, loc = self._do_get(name, group, namespace) 2020-06-02 14:36:08.892 124358 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 2649, in _do_get 2020-06-02 14:36:08.892 124358 ERROR neutron info = self._get_opt_info(name, group) 2020-06-02 14:36:08.892 124358 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 2849, in _get_opt_info 2020-06-02 14:36:08.892 124358 ERROR neutron raise NoSuchOptError(opt_name, group) 2020-06-02 14:36:08.892 124358 ERROR neutron oslo_config.cfg.NoSuchOptError: no such option AGENT in group [DEFAULT] 2020-06-02 14:36:08.892 124358 ERROR neutron 2020-06-02 14:36:08.892 124358 ERROR neutron During handling of the above exception, another exception occurred: 2020-06-02 14:36:08.892 124358 ERROR neutron 2020-06-02 14:36:08.892 124358 ERROR neutron Traceback (most recent call last): 2020-06-02 14:36:08.892 124358 ERROR neutron File "/usr/bin/neutron-ipset-cleanup", line 10, in 2020-06-02 14:36:08.892 124358 ERROR neutron sys.exit(main()) 2020-06-02 14:36:08.892 124358 ERROR neutron File "/usr/lib/python3/dist-packages/neutron/cmd/ipset_cleanup.py", line 98, in main 2020-06-02 14:36:08.892 124358 ERROR neutron cleanup_ipsets(conf) 2020-06-02 14:36:08.892 124358 ERROR neutron File "/usr/lib/python3/dist-packages/neutron/cmd/ipset_cleanup.py", line 78, in cleanup_ipsets 2020-06-02 14:36:08.892 124358 ERROR neutron ipsets = utils.execute(cmd, run_as_root=True) 2020-06-02 14:36:08.892 124358 ERROR neutron File "/usr/lib/python3/dist-packages/neutron/agent/linux/utils.py", line 120, in execute 2020-06-02 14:36:08.892 124358 ERROR neutron if run_as_root and cfg.CONF.AGENT.root_helper_daemon: 2020-06-02 14:36:08.892 124358 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 2201, in __getattr__ 2020-06-02 14:36:08.892 124358 ERROR neutron raise NoSuchOptError(name) 2020-06-02 14:36:08.892 124358 ERROR neutron oslo_config.cfg.NoSuchOptError: no such option AGENT in group [DEFAULT] 2020-06-02 14:36:08.892 124358 ERROR neutron The config file does have a AGENT section, but from cursory view of the source code of the neutron-ipset-cleanup command line tool it does not initialize this section of the configuration. I think this is a simple case of bit-rot and augmenting the command line source code to initializing the missing section makes it run successfully. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1881771/+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 1900851] [NEW] Cannot Create Port with Fixed IP Address
Public bug reported:
With Ussuri on Ubuntu 20.04, I can create port with fixed IP address by
CLI but I cannot do the same by Horizon GUI. I find some error like
following on /var/log/apache2/error.log
openstack_dashboard.dashboards.project.networks.ports.workflows Failed
to create a port for network 91f04dfb-7f69-4050-8b3b-142ee555ae55:
dictionary keys changed during iteration
By more inspection, I can find that horizon never send that create port
request to neutron. So I think it is horizon problem. Is this expected
result or is this horizon bug? Is this related to policy?
Following debug logs maybe related too.
[Wed Oct 21 17:48:06.123807 2020] [wsgi:error] [pid 3095280:tid
140002354386688] [remote 192.168.202.12:60886] DEBUG neutronclient.client GET
call to neutron for http://10.7.55.18:9696/v2.0/extensions used request id
req-95db8d1f-387b-492b-aff6-8238f09e504d
[Wed Oct 21 17:48:06.125925 2020] [wsgi:error] [pid 3095280:tid
140002354386688] [remote 192.168.202.12:60886] DEBUG django.template Exception
while resolving variable 'add_to_field' in template
'horizon/common/_workflow.html'.
[Wed Oct 21 17:48:06.126064 2020] [wsgi:error] [pid 3095280:tid
140002354386688] [remote 192.168.202.12:60886]
django.template.base.VariableDoesNotExist: Failed lookup for key [add_to_field]
in [{'True': True, 'False': False, 'None': None}, {'csrf_token':
._get_val at 0x7f54c8e30f70>>,
'LANGUAGES': (('cs', 'Czech'), ('de', 'German'), ('en', 'English'), ('en-au',
'Australian English'), ('en-gb', 'British English'), ('eo', 'Esperanto'),
('es', 'Spanish'), ('fr', 'French'), ('id', 'Indonesian'), ('it', 'Italian'),
('ja', 'Japanese'), ('ko', 'Korean (Korea)'), ('pl', 'Polish'), ('pt-br',
'Portuguese (Brazil)'), ('ru', 'Russian'), ('tr', 'Turkish'), ('zh-cn',
'Simplified Chinese'), ('zh-tw', 'Chinese (Taiwan)')), 'LANGUAGE_CODE': 'en',
'LANGUAGE_BIDI': False, 'request': ,
'MEDIA_URL': '/horizon/media/', 'STATIC_URL': '/horizon/static/', 'messages':
, 'DEFAULT_MESSAGE_LEVELS': {'DEBUG': 10, 'INFO': 20, 'SUCCESS':
25, 'WARNING': 30, 'ERROR': 40}, 'HORIZON_CONFIG': , 'True': True, 'False': False, 'authorized_tenants':
[http://10.7.55.18:5000/v3/projects/84725e39c7a9462495e2cb6ae0cd111b'},
name=admin, options={}, parent_id=default, tags=[]>], 'keystone_providers':
{'support': False}, 'regions': {'support': False, 'current': {'endpoint':
'http://10.7.55.18:5000/v3/', 'name': 'Default Region'}, 'available': []},
'WEBROOT': '/horizon/', 'USER_MENU_LINKS': [{'name': 'OpenStack RC File',
'icon_classes': ['fa-download'], 'url': 'horizon:project:api_access:openrc'}],
'LOGOUT_URL': '/horizon/auth/logout/', 'profiler_enabled': False, 'JS_CATALOG':
'horizon+openstack_dashboard'}, {}, {'network_id':
'91f04dfb-7f69-4050-8b3b-142ee555ae55', 'view':
, 'modal_backdrop': 'static', 'workflow': , 'REDIRECT_URL': None, 'layout': ['modal'], 'modal': True},
{'entry_point': 'create_info'}]
** Affects: horizon
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1900851
Title:
Cannot Create Port with Fixed IP Address
Status in OpenStack Dashboard (Horizon):
New
Bug description:
With Ussuri on Ubuntu 20.04, I can create port with fixed IP address
by CLI but I cannot do the same by Horizon GUI. I find some error like
following on /var/log/apache2/error.log
openstack_dashboard.dashboards.project.networks.ports.workflows Failed
to create a port for network 91f04dfb-7f69-4050-8b3b-142ee555ae55:
dictionary keys changed during iteration
By more inspection, I can find that horizon never send that create
port request to neutron. So I think it is horizon problem. Is this
expected result or is this horizon bug? Is this related to policy?
Following debug logs maybe related too.
[Wed Oct 21 17:48:06.123807 2020] [wsgi:error] [pid 3095280:tid
140002354386688] [remote 192.168.202.12:60886] DEBUG neutronclient.client GET
call to neutron for http://10.7.55.18:9696/v2.0/extensions used request id
req-95db8d1f-387b-492b-aff6-8238f09e504d
[Wed Oct 21 17:48:06.125925 2020] [wsgi:error] [pid 3095280:tid
140002354386688] [remote 192.168.202.12:60886] DEBUG django.template Exception
while resolving variable 'add_to_field' in template
'horizon/common/_workflow.html'.
[Wed Oct 21 17:48:06.126064 2020] [wsgi:error] [pid 3095280:tid
140002354386688] [remote 192.168.202.12:60886]
django.template.base.VariableDoesNotExist: Failed lookup for key [add_to_field]
in [{'True': True, 'False': False, 'None': None}, {'csrf_token':
._get_val at 0x7f54c8e30f70>>,
'LANGUAGES': (('cs', 'Czech'), ('de', 'German'), ('en', 'English'), ('en-au',
'Australian English'), ('en-gb', 'British English'), ('eo', 'Esperanto'),
('es', 'Spanish'), ('fr', 'French'), ('id', 'Indonesian'), ('it', 'Italian'),
('ja', 'Japanese'), ('ko', 'Korean (Korea)'),
[Yahoo-eng-team] [Bug 1900843] [NEW] Nova live-migration fails because duplicate records in neutron's ml2_port_bindings table
Public bug reported:
Env: Ussuri environment with 1 controller + 2 compute nodes.
Reproduce steps:
1. Create a VM at comp;
2. Live-migrate the VM from comp to comp2;
3. Live-migration success;
4. Live-migrate the VM from the comp2 to comp;
5. Live migration fail
I find that there are duplicate records in the neutron's
"ml2_port_bindings" table:
MariaDB [neutron]> select * from ml2_port_bindings where
port_id="71c3a3c7-d853-4b26-9975-50b99c449371";
+--+---+--+---+---+---+--+
| port_id | host | vif_type | vnic_type | profile
| vif_details
| status |
+--+---+--+---+---+---+--+
| 71c3a3c7-d853-4b26-9975-50b99c449371 | comp | unbound | normal|
{"migrating_to": "comp2"} |
| INACTIVE |
| 71c3a3c7-d853-4b26-9975-50b99c449371 | comp2 | ovs | normal| {}
| {"connectivity": "l2", "port_filter": true,
"ovs_hybrid_plug": false, "datapath_type": "system", "bridge_name": "br-int"} |
ACTIVE |
+--+---+--+---+---+---+--+
After removing the "INACTIVE" record, I do the step4( live migrate the
VM from host2 to host1 ) success.
I find a similar bug at https://bugs.launchpad.net/nova/+bug/1822884.
But it seems that it is different from this bug.
** Affects: nova
Importance: Undecided
Status: New
** Description changed:
Env: Ussuri environment with 1 controller + 2 compute nodes.
Reproduce steps:
- 1. Create a VM at host1;
- 2. Live-migrate the VM from host1 to host2;
+ 1. Create a VM at comp;
+ 2. Live-migrate the VM from comp to comp2;
3. Live-migration success;
- 4. Live-migrate the VM from the host2 to host1;
+ 4. Live-migrate the VM from the comp2 to comp;
5. Live migration fail
I find that there are duplicate records in the neutron's
"ml2_port_bindings" table:
MariaDB [neutron]> select * from ml2_port_bindings where
port_id="71c3a3c7-d853-4b26-9975-50b99c449371";
+--+---+--+---+---+---+--+
| port_id | host | vif_type | vnic_type |
profile | vif_details
- | status |
+ | status |
+--+---+--+---+---+---+--+
| 71c3a3c7-d853-4b26-9975-50b99c449371 | comp | unbound | normal|
{"migrating_to": "comp2"} |
- | INACTIVE |
+ | INACTIVE |
| 71c3a3c7-d853-4b26-9975-50b99c449371 | comp2 | ovs | normal| {}
| {"connectivity": "l2", "port_filter": true,
"ovs_hybrid_plug": false, "datapath_type": "system", "bridge_name": "br-int"} |
ACTIVE |
+--+---+--+---+---+---+--+
After removing the "INACTIVE" record, I do the step4( live migrate the
VM from host2 to host1 ) success.
-
- I find a similar bug at https://bugs.launchpad.net/nova/+bug/1822884. But it
seems that it is different with this bug.
+ I find a similar bug at https://bugs.launchpad.net/nova/+bug/1822884.
+ But it seems that it is different from this bug.
--
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/1900843
Title:
Nova live-migration fails because duplicate records in neutron's
ml2_port_bindings table
Status in OpenStack Compute (nova):
New
Bug description:
Env: Ussuri environment with 1 controller + 2 compute nodes.
Reproduce steps:
1. Create a VM at comp;
2. Live-migrate the VM from comp to comp2;
3. Live-migration success;
4. Live-migrate the VM from the comp2 to comp;
5. Live migration fail
I find that there are duplicate records in the neutron's
"
[Yahoo-eng-team] [Bug 1900837] [NEW] cloud-init resets permissions on log file after reboot
Public bug reported: In attempting to apply CIS security guidelines onto an Ubuntu system it was found that changing the log files in /var/log to 640, that on a reboot cloud-init would reset the permissions to 644. As long as cloud- init can write to the file it should be ok to alter the permissions without issue. ** Affects: cloud-init Importance: High Status: Triaged -- 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/1900837 Title: cloud-init resets permissions on log file after reboot Status in cloud-init: Triaged Bug description: In attempting to apply CIS security guidelines onto an Ubuntu system it was found that changing the log files in /var/log to 640, that on a reboot cloud-init would reset the permissions to 644. As long as cloud-init can write to the file it should be ok to alter the permissions without issue. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1900837/+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 1716868] Re: config file is not read
As Pike is no longer a supported release, I'm marking this bug wontfix. If it occurs with still-supported versions of the Horizon package, please update this bug with that information. ** Changed in: cloud-archive Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1716868 Title: config file is not read Status in Ubuntu Cloud Archive: Won't Fix Status in OpenStack Dashboard (Horizon): Invalid Bug description: we are running horizon on an Ubuntu 16 cluster with the official repos for the new pike release and figured out that the configuration file /etc/openstack-dashboard/local_settings.py is no longer read. it seems the symlink /usr/share/openstack- dashboard/openstack_dashboard/local/local_settings.py is no longer working. we removed that symlink and copied the file directly into /usr/share/openstack-dashboard/openstack_dashboard/local/ which seems to help for the moment. installed package: python-django-horizon - 3:12.0.0-0ubuntu1~cloud0 OS: Ubuntu 16.04.3 LTS apache virtual host config: http://paste.openstack.org/show/621008/ file permissions: -rw-r--r-- 1 root horizon 34573 Sep 13 10:01 /etc/openstack-dashboard/local_settings.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1716868/+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 1773967] Re: Application credentials can't be used with group-only role assignments
** Changed in: keystone (Ubuntu) Status: Confirmed => Fix Released ** Changed in: cloud-archive Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1773967 Title: Application credentials can't be used with group-only role assignments Status in Ubuntu Cloud Archive: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystone package in Ubuntu: Fix Released Bug description: If a user only has a role assignment on a project via a group membership, the user can create an application credential for the project but it cannot be used. If someone tries to use it, the debug logs will report: User has no access to project We need to ensure that any application credential that is created can be used so long as it is not expired and the user exists and has access to the project they created the application credential for. If we decide that application credentials should not be valid for users who have no explicit role assignments on projects, then we should prevent it from being created and provide a useful message to the user. This is probably related to https://bugs.launchpad.net/keystone/+bug/1589993 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1773967/+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
