[Yahoo-eng-team] [Bug 1545584] Re: OVN devstack: Network creation fails when a VM with provider and private network interface is activatied
** Project changed: neutron => networking-ovn
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1545584
Title:
OVN devstack: Network creation fails when a VM with provider and
private network interface is activatied
Status in networking-ovn:
New
Bug description:
We have a 5 node OVN devstack installation. We have created networks,
subnets, routers and activated VMs on private network. Then added
provider network and activated VMs with both private and provider
network interface. In this devstack implementation we also started
two ovsdb servers one with 6640 port and another with 6641. OVSDB
6641 connects to OVN contorller plug-in.
When a VM with both private and provider interface is activated, I
see Internal server error, neutron server log shows connection lost
in the middle of a mysql operation.
Rally benchmark is enhanced to activate a VM with both network
interfaces.
Rally errors:
016-02-12 13:46:36.403 28528 DEBUG neutronclient.client [-] RESP: 500
{'Date': 'Fri, 12 Feb 2016 19:46:36 GMT', 'Connection': 'keep-alive',
'Content-Type':
'application/json; charset=UTF-8', 'Content-Length': '150',
'X-Openstack-Request-Id': 'req-a5d49508-8501-4802-a46b-674d36a46d23'}
{"NeutronError": {"message":
"Request Failed: internal server error while processing your request.",
"type": "HTTPInternalServerError", "detail": ""}} http_log_resp
/usr/lib/python2.7/site-packages/neutronclient/common/utils.py:146
2016-02-12 13:46:36.403 28528 DEBUG neutronclient.v2_0.client [-] Error
message: {"NeutronError": {"message": "Request Failed: internal server error
while processing your request.", "type": "HTTPInternalServerError", "detail":
""}} _handle_fault_response
/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py:176
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner [-] Request Failed:
internal server error while processing your request.
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner Traceback (most recent
call last):
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/usr/lib/python2.7/site-packages/rally/task/runner.py", line 64, in
_run_scenario_once
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner
method_name)(**kwargs) or scenario_output
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/home/stack/sahil/OVN/rally_runs/cnps_ovn.py", line 100, in
boot_server_overlay_network
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner
self.wait_for_dhcp_port_up()
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/home/stack/sahil/OVN/rally_runs/cnps_ovn.py", line 200, in
wait_for_dhcp_port_up
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner dhcp_port_id =
self._get_dhcp_port(network_id, poll_count=poll_count)["id"]
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/usr/lib/python2.7/site-packages/rally/cnp/cnp_base_scenario.py", line 510, in
_get_dhcp_port
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner
device_owner=device_owner)
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 102, in
with_params
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner ret =
self.function(instance, *args, **kwargs)
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 547, in
list_ports
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner **_params)
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 307, in
list
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner for r in
self._pagination(collection, path, **params):
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 320, in
_pagination
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner res =
self.get(path, params=params)
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 293, in
get
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner headers=headers,
params=params)
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 270, in
retry_request
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner headers=headers,
params=params)
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner res =
self.get(path, params=params)
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner File
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 293, in
get
2016-02-12 13:46:36.405 28528 ERROR rally.task.runner headers=headers,
params=params)
[Yahoo-eng-team] [Bug 1540064] Re: neutron router-update --routes should prevent user from adding existing cidr
** Changed in: neutron Status: New => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1540064 Title: neutron router-update --routes should prevent user from adding existing cidr Status in neutron: Opinion Bug description: Find this when do some debug. Steps to reproduce: 1) I have a router with some subnets connected to it, for example 100.0.0.0/24 100.0.1.0/24. There will be some routes that are created by the kernel for the router interfaces. # ip r 100.0.1.0/24 dev qr-fef63af2-82 proto kernel scope link src 100.0.1.1 100.0.0.0/24 dev qr-af2ae2b0-8c proto kernel scope link src 100.0.0.1 2) I update the extra route by (just for testing) neutron router-update router1 --route destination=100.0.1.0/24,nexthop=100.0.0.3 3) The route that was for 100.0.1.0/24 will be replaced. # ip r 100.0.1.0/24 via 100.0.0.3 dev qr-af2ae2b0-8c 100.0.0.0/24 dev qr-af2ae2b0-8c proto kernel scope link src 100.0.0.1 4) I clear the extra route that I added by using neutron router-update router1 --no-routes The I get the following routes in router namespace: # ip r 100.0.0.0/24 dev qr-af2ae2b0-8c proto kernel scope link src 100.0.0.1 As a result, I lost the connection to 100.0.1.0/24. I think neutron should prevent user from adding extra routes to the existing cidrs that have been connected to router(as interface or as gateway). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1540064/+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 1542819] Re: The details of security group contains "null"
** Project changed: neutron => python-neutronclient ** Changed in: python-neutronclient Importance: Undecided => Wishlist ** Tags added: rfe ** Changed in: python-neutronclient Status: New => Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1542819 Title: The details of security group contains "null" Status in python-neutronclient: Triaged Bug description: When using security group, I found the some output of security group will be "null". This happens when the value is not specified. Under the same condition, "neutron security-group-rule-list" will report "any". However, "neutron security-group-rule-show" will report empty. The details can be found at [1]. I think, if the value it not specified for a security group rule, we could show "any" to user. This will make the output be consistent, and the more easily to understand. [1] http://paste.openstack.org/show/486190/ To manage notifications about this bug go to: https://bugs.launchpad.net/python-neutronclient/+bug/1542819/+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 1537348] Re: neutron-db-manage: add has_offline_migrations command
** Project changed: neutron => openstack-manuals -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1537348 Title: neutron-db-manage: add has_offline_migrations command Status in openstack-manuals: New Bug description: https://review.openstack.org/248190 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit eb084af29da6b8b9bb5608f294acaaa44f923895 Author: Ihar Hrachyshka Date: Fri Nov 20 18:23:08 2015 +0100 neutron-db-manage: add has_offline_migrations command This command should be used by operators and deployment tools to determine whether full neutron-server shutdown is needed for database upgrade. The change also makes neutron-db-manage tool to return the cumulative result of commands being issued (in most cases it will still be 0 only, since our command handlers implicitly return None). DocImpact: Update doc to add new command 'has_offline_migrations' to 'neutron-db-manage' tool. The command determines whether full neutron-server shutdown is needed for database upgrade. Closes-Bug: #1519118 Change-Id: I7c5a4882ad4f80459ebe69c9a9c43cc60ce50200 Co-Authored-By: Martin Hickey To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-manuals/+bug/1537348/+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 1479243] Re: _core_plugin should be put into plugins\common\utils.py
Hi huangpengtaohw, Setting to invalid. Re-open if you think differently. Thanks, Martin ** Changed in: neutron Status: Incomplete => 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/1479243 Title: _core_plugin should be put into plugins\common\utils.py Status in neutron: Invalid Bug description: the below function: @property def _core_plugin(self): return manager.NeutronManager.get_plugin() is put into many class 'L3_NAT_dbonly_mixin', 'Firewall_db_mixin', and so on. as a common useful function , it should be put in ' plugins\common\utils.py' file to avoid many definition. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1479243/+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 1527483] Re: VPNaaS - No providers specified for 'VPN' service
** Project changed: neutron => devstack ** Changed in: devstack Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1527483 Title: VPNaaS - No providers specified for 'VPN' service Status in devstack: Fix Committed Bug description: VPNaaS - No providers specified for 'VPN' service - when trying to start neutron on devstack # devstack_logs/screen-q-svc.log ERROR neutron.services.service_base [req-f1f03224-2935-4f35-b25f-5db85c818005 None None] No providers specified for 'VPN' service, exiting q-svc failed to start # devstack_logs/stack.sh.txt 2015-12-18 05:40:29.738 | + die 2200 'Neutron did not start' 2015-12-18 05:40:29.738 | + local exitcode=0 2015-12-18 05:40:29.738 | [Call Trace] 2015-12-18 05:40:29.738 | ./stack.sh:1246:start_neutron_service_and_check 2015-12-18 05:40:29.738 | /home/ubuntu/devstack/lib/neutron-legacy:693:test_with_retry 2015-12-18 05:40:29.738 | /home/ubuntu/devstack/functions-common:2200:die 2015-12-18 05:40:29.741 | [ERROR] /home/ubuntu/devstack/functions-common:2200 Neutron did not start 2015-12-18 05:40:30.744 | Error on exit To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1527483/+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 1199963] Re: Neutron does not use Oslo for config generator
** Changed in: neutron Status: In Progress => Fix Released ** Changed in: devstack Status: In Progress => 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/1199963 Title: Neutron does not use Oslo for config generator Status in devstack: Fix Released Status in neutron: Fix Released Bug description: We should update Neutron for using Oslo when we generate configuration files. Here are the steps : - Add generator.py from Oslo - Add generator bash script used by other projects to generate configuration files - Update openstack-common.conf file - Generate configuration file To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1199963/+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 1525275] [NEW] Loading configuration items from keystoneauth is causing warnings
Public bug reported: Neutron uses the oslo-config-generator to automatically generate configuration files. Some configuration items are authentication items retrieved from keystone like 'domain-id', 'password' etc. These items are retrieved in https://github.com/openstack/neutron/blob/master/neutron/opts.py#L275. The following warnings are now been output when you run the tox target to generate config items (tox -e genconfig) or pep8 as it also generates the config files: /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option auth_type should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option auth_section should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option auth-url should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option default-domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option default-domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option password should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option tenant-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option tenant-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option trust-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-name should have a type derived from types.ConfigType instead of warnings.warn(msg) These warnings may have been introduced with the following change: https://github.com/openstack/neutron/commit/a37e11f637b21785307e14e9725de3db14a1d37b ** Affects: keystone Importance: Undecided Status: New ** Description changed: Neutron uses the oslo-config-generator to automatically generate configuration files. Some configuration items are authentication items retrieved from keystone like 'domain-id', 'password' etc. These items are retrieved in https://github.com/openstack/neutron/blob/mast
[Yahoo-eng-team] [Bug 1199963] Re: Neutron does not use Oslo for config generator
** Also affects: devstack Importance: Undecided Status: New ** Changed in: devstack Assignee: (unassigned) => Martin Hickey (martin-hickey) ** Changed in: devstack Status: New => 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/1199963 Title: Neutron does not use Oslo for config generator Status in devstack: In Progress Status in neutron: In Progress Bug description: We should update Neutron for using Oslo when we generate configuration files. Here are the steps : - Add generator.py from Oslo - Add generator bash script used by other projects to generate configuration files - Update openstack-common.conf file - Generate configuration file To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1199963/+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 1046121] Re: dhcp should never be enabled for a router external net
Patch https://review.openstack.org/#/c/234196/ abandoned until networking guide team plans on adding a scenario where you can boot on external networks. ** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: neutron Assignee: Martin Hickey (martin-hickey) => (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1046121 Title: dhcp should never be enabled for a router external net Status in neutron: In Progress Status in openstack-manuals: New Bug description: it doesn't make sense in the existing model, as the router IPs and the floating IPs allocated from an external net never make DHCP requests. I don't believe there is any significant additional harm caused by this though, other than unneeded CPU churn from DHCP agent and dnsmasq, and a burned IP address allocated for a DHCP port. One tricky issue is that DHCP is enabled by default, so the question is whether we should fail if the user does not explicitly disable it when creating a network, or if we should just automatically set it to False. Unfortunately, I don't think we can tell the difference between a this value default to true and it being explicitly set to true, so it seems that if we want to prevent it from being set to true in the API, we should require it to be set to False. We also need to prevent it from being set to True on an update. Another option would be to ignore the value set in the API and just have the DHCP agent ignore networks for which router:external =True. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1046121/+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 1504536] Re: Provide stevedore aliases for interface_driver option
** Also affects: devstack Importance: Undecided Status: New ** Changed in: devstack Assignee: (unassigned) => Martin Hickey (martin-hickey) ** Changed in: devstack Status: New => 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/1504536 Title: Provide stevedore aliases for interface_driver option Status in devstack: In Progress Status in neutron: In Progress Bug description: Currently, we require to set the full import path for those drivers. It's both not user friendly, and error prone in case we decide later to move the code to some other place. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1504536/+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 1478887] [NEW] Create network does not reflect the underlying network configuration of the region
Public bug reported: When creating a network from Admin->System->Networks, the "Provider Network Type" field lists all supported network types for Neutron. It would be better if this list corresponded to the network configuration supported for the selected region. This would avoid a user selecting a type which is not supported and getting a generic "Error: Failed to create network ". I understand that this might be more a feature than a bug as it probably requires some coordination between Neutron and Horizon. ** 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/1478887 Title: Create network does not reflect the underlying network configuration of the region Status in OpenStack Dashboard (Horizon): New Bug description: When creating a network from Admin->System->Networks, the "Provider Network Type" field lists all supported network types for Neutron. It would be better if this list corresponded to the network configuration supported for the selected region. This would avoid a user selecting a type which is not supported and getting a generic "Error: Failed to create network ". I understand that this might be more a feature than a bug as it probably requires some coordination between Neutron and Horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1478887/+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 1365359] [NEW] Ability to disable more than one domain at a time
Public bug reported: It would be nice to have functionality where you could select multiple domains and set them to be disabled at one time. This functionality would compliment the delete functionality where you can bulk delete domains. ** 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/1365359 Title: Ability to disable more than one domain at a time Status in OpenStack Dashboard (Horizon): New Bug description: It would be nice to have functionality where you could select multiple domains and set them to be disabled at one time. This functionality would compliment the delete functionality where you can bulk delete domains. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1365359/+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 1346389] [NEW] Disk unit missing in Overview Usage Summary
Public bug reported: In Project and Admin Overview pages, the Disk column in the Usage Summary table does not contain a unit. It would be better to add the unit for clarity. ** 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/1346389 Title: Disk unit missing in Overview Usage Summary Status in OpenStack Dashboard (Horizon): New Bug description: In Project and Admin Overview pages, the Disk column in the Usage Summary table does not contain a unit. It would be better to add the unit for clarity. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1346389/+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
