[Yahoo-eng-team] [Bug 1825516] Re: Success Message should appear after volume creation and deletion
[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.] ** Changed in: horizon Status: Incomplete => Expired -- 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/1825516 Title: Success Message should appear after volume creation and deletion Status in OpenStack Dashboard (Horizon): Expired Bug description: Success Message should appear after volume creation and deletion: This is just suggetsion for the UI Side. As all the services like network topology, image, flavor, etc show success when it is created and deleted. The same thing should happen in volume as well. Volume only give us informative message. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1825516/+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 1833489] [NEW] Examples have errors in the Tutorials section of the horizon documentation
Public bug reported:
Create the dashboard and panel according to the horizon document(Refer：
Tutorial: Building a Dashboard using Horizon)
But there was an error when I started horizon：
ystem check identified no issues (0 silenced).
June 20, 2019 - 01:36:02
Django version 1.11.20, using settings 'openstack_dashboard.settings'
Starting development server at http://192.168.117.132:8000/
Quit the server with CONTROL-C.
WARNING django.request Not Found: /favicon.ico
WARNING django.server "GET /favicon.ico HTTP/1.1" 404 4687
INFO django.server - Broken pipe from ('192.168.117.1', 61256)
DEBUG:stevedore.extension:found extension EntryPoint.parse('http =
oslo_policy._external:HttpCheck')
DEBUG:stevedore.extension:found extension EntryPoint.parse('https =
oslo_policy._external:HttpsCheck')
INFO django.server "GET /auth/login/?next=/admin/ HTTP/1.1" 200 9504
INFO django.server "GET /i18n/js/horizon+openstack_dashboard/ HTTP/1.1" 200 3217
WARNING django.request Not Found: /dashboard/header/
WARNING django.server "GET /dashboard/header/?next=/admin/ HTTP/1.1" 404 4715
INFO django.server "GET /admin/ HTTP/1.1" 200 37382
INFO django.server - Broken pipe from ('192.168.117.1', 61257)
INFO openstack_auth.forms Login successful for user "admin" using domain
"Default", remote address 192.168.117.1.
INFO django.server "POST /auth/login/ HTTP/1.1" 302 0
INFO django.server "GET /admin/ HTTP/1.1" 200 37377
INFO django.server "GET /i18n/js/horizon+openstack_dashboard/ HTTP/1.1" 200 3217
WARNING django.request Not Found: /dashboard/header/
WARNING django.server "GET /dashboard/header/ HTTP/1.1" 404 4704
ERROR django.request Internal Server Error: /mydashboard/
Traceback (most recent call last):
File
"/usr/local/lib/python2.7/dist-packages/django/core/handlers/exception.py",
line 41, in inner
response = get_response(request)
File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py",
line 187, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py",
line 185, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
return view_func(request, *args, **kwargs)
File "/opt/stack/horizon/horizon/decorators.py", line 52, in dec
return view_func(request, *args, **kwargs)
File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
return view_func(request, *args, **kwargs)
File "/opt/stack/horizon/horizon/decorators.py", line 113, in dec
return view_func(request, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py",
line 68, in view
return self.dispatch(request, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py",
line 88, in dispatch
return handler(request, *args, **kwargs)
File "/opt/stack/horizon/horizon/tabs/views.py", line 139, in get
context = self.get_context_data(**kwargs)
File "/opt/stack/horizon/horizon/tables/views.py", line 106, in
get_context_data
context = super(MultiTableMixin, self).get_context_data(**kwargs)
File "/opt/stack/horizon/horizon/tabs/views.py", line 55, in get_context_data
exceptions.handle(self.request)
File "/opt/stack/horizon/horizon/exceptions.py", line 348, in handle
six.reraise(exc_type, exc_value, exc_traceback)
File "/opt/stack/horizon/horizon/tabs/views.py", line 53, in get_context_data
context["tab_group"].load_tab_data()
File "/opt/stack/horizon/horizon/tabs/base.py", line 178, in load_tab_data
exceptions.handle(self.request)
File "/opt/stack/horizon/horizon/exceptions.py", line 348, in handle
six.reraise(exc_type, exc_value, exc_traceback)
File "/opt/stack/horizon/horizon/tabs/base.py", line 175, in load_tab_data
tab._data = tab.get_context_data(self.request)
File "/opt/stack/horizon/horizon/tabs/base.py", line 533, in get_context_data
self.load_table_data()
File "/opt/stack/horizon/horizon/tabs/base.py", line 512, in load_table_data
% {'func_name': func_name, 'cls_name': cls_name})
NotImplementedError: You must define a get_instane_data method on InstanceTab.
ERROR django.server "GET /mydashboard/ HTTP/1.1" 500 395237
WARNING django.request Not Found: /favicon.ico
WARNING django.server "GET /favicon.ico HTTP/1.1" 404 4684
[2019-06-20 01:39:30,714 pyinotify ERROR] The pathname
'/opt/stack/horizon/openstack_dashboard/dashboards/mydashboard/mypanel/tabs.py'
of this watch at
0x7ff6c3ebbb18> dir=False > has probably changed and couldn't be updated, so it
cannot be trusted anymore. To fix this error move directories/files only
between watched parents directories, in this case e.g. put a watch on
'/opt/stack/horizon/openstack_dashboard/dashboards/mydashboard/mypanel'.
ERROR:pyinotify:The pathname
'/opt/stack/horizon/openstack_dashboard/dashboards/mydashboard/mypanel/tabs.py'
of
[Yahoo-eng-team] [Bug 1833460] [NEW] cloud_tests on lxd snap error exporting image
Public bug reported:
Attempting a cloud_test run on lxd platform had this issue.
(diglett) cloud-init % tox -r -e citest -- run --verbose --platform=lxd
--os-name centos70 --rpm ~/cloud-init-19.1+44.g12efb6d3-1.el7.noarch.rpm
--result /tmp/centos7-result.yaml
GLOB sdist-make: /srv/tmp/rharper/cloud-init/setup.py
citest create: /srv/tmp/rharper/cloud-init/.tox/citest
citest installdeps: -r/srv/tmp/rharper/cloud-init/integration-requirements.txt
citest inst: /srv/tmp/rharper/cloud-init/.tox/.tmp/package/1/cloud-init-19.1.zip
citest installed:
asn1crypto==0.24.0,attrs==19.1.0,bcrypt==3.1.6,boto3==1.5.9,botocore==1.8.50,certifi==2019.6.16,cffi==1.12.3,chardet==3.0.4,cloud-init==19.1,configobj==5.0.6,cryptography==2.7,docutils==0.14,idna==2.8,Jinja2==2.10.1,jmespath==0.9.4,jsonpatch==1.23,jsonpointer==2.0,jsonschema==3.0.1,linecache2==1.0.0,MarkupSafe==1.1.1,oauthlib==3.0.1,paramiko==2.4.1,pbr==5.3.0,pkg-resources==0.0.0,pyasn1==0.4.5,pycparser==2.19,pylxd==2.2.7,PyNaCl==1.3.0,pyrsistent==0.15.2,python-dateutil==2.8.0,python-simplestreams==0.1.0,PyYAML==5.1.1,requests==2.22.0,requests-toolbelt==0.9.1,requests-unixsocket==0.1.5,s3transfer==0.1.13,six==1.12.0,traceback2==1.4.0,unittest2==1.1.0,urllib3==1.25.3,ws4py==0.5.1
citest run-test-pre: PYTHONHASHSEED='2218838469'
citest runtests: commands[0] |
/srv/tmp/rharper/cloud-init/.tox/citest/bin/python -m tests.cloud_tests run
--verbose --platform=lxd --os-name centos70 --rpm
/home/rharper/cloud-init-19.1+44.g12efb6d3-1.el7.noarch.rpm --result
/tmp/centos7-result.yaml
2019-06-19 19:18:44,550 - tests.cloud_tests - DEBUG - running with args:
Namespace(data_dir=None, deb=None, feature_override={}, os_name=['centos70'],
platform=['lxd'], ppa=None, preserve_data=False, preserve_instance=False,
quiet=False, repo=None, result='/tmp/centos7-result.yaml',
rpm='/home/rharper/cloud-init-19.1+44.g12efb6d3-1.el7.noarch.rpm', script=None,
subcmd='run',
test_config=['/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/bugs/lp1511485.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/bugs/lp1611074.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/bugs/lp1628337.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/add_apt_repositories.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/alter_completion_message.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/configure_instance_trusted_ca_certificates.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/configure_instances_ssh_keys.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/including_user_groups.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/install_arbitrary_packages.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/install_run_chef_recipes.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/run_apt_upgrade.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/run_commands.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/run_commands_first_boot.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/setup_run_puppet.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/writing_out_arbitrary_files.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/main/command_output_simple.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_conf.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_disable_suites.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_primary.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_proxy.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_security.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_sources_key.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_sources_keyserver.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_sources_list.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_sources_ppa.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_pipelining_disable.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_pipelining_os.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/bootcmd.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/byobu.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/ca_certs.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/debug_disable.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/debug_enable.yaml',
[Yahoo-eng-team] [Bug 1774252] Re: Resize confirm fails if nova-compute is restarted after resize
*** This bug is a duplicate of bug 1774249 *** https://bugs.launchpad.net/bugs/1774249 ** This bug has been marked a duplicate of bug 1774249 update_available_resource will raise DiskNotFound after resize but before confirm -- 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/1774252 Title: Resize confirm fails if nova-compute is restarted after resize Status in OpenStack Compute (nova): New Bug description: Originally reported in RH bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1584315 Reproduced on OSP12 (Pike). After resizing an instance but before confirm, update_available_resource will fail on the source compute due to bug 1774249. If nova compute is restarted at this point before the resize is confirmed, the update_available_resource period task will never have succeeded, and therefore ResourceTracker's compute_nodes dict will not be populated at all. When confirm calls _delete_allocation_after_move() it will fail with ComputeHostNotFound because there is no entry for the current node in ResourceTracker. The error looks like: 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [req-4f7d5d63-fc05-46ed-b505-41050d889752 09abbd4893bb45eea8fb1d5e40635339 d4483d13a6ef41b2ae575ddbd0c59141 - default default] [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] Setting instance vm_state to ERROR: ComputeHostNotFound: Compute host compute-1.localdomain could not be found. 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] Traceback (most recent call last): 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 7445, in _error_out_instance_on_exception 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] yield 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 3757, in _confirm_resize 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] migration.source_node) 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 3790, in _delete_allocation_after_move 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] cn_uuid = rt.get_node_uuid(nodename) 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] File "/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py", line 155, in get_node_uuid 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] raise exception.ComputeHostNotFound(host=nodename) 2018-05-30 13:42:19.239 1 ERROR nova.compute.manager [instance: 1374133a-2c08-4a8f-94f6-729d4e58d7e0] ComputeHostNotFound: Compute host compute-1.localdomain could not be found. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1774252/+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 1833455] [NEW] [RBAC] User is not allowed to create port with fixed IP on shared network via RBAC
Public bug reported: 1. Create tenant1 with user1 and tenant2 with user 2, assign testrole to both 2, Change the default policy.json to allow creation of ports with fixed IP address in a shared network: ()[root@controller-2 /]# diff /etc/neutron/policy.json /etc/neutron/policy.json.bkp 78c78 < "create_port:fixed_ips:ip_address": "rule:context_is_advsvc or rule:admin_or_network_owner or rule:shared", --- > "create_port:fixed_ips:ip_address": "rule:context_is_advsvc or rule:admin_or_network_owner", 3. As user1 create a network and share it via RBAC to tenant2: user1 (overcloud) [stack@undercloud-0 ~]$ openstack network create rbacnet1 +---+--+ | Field | Value| +---+--+ | admin_state_up| UP | | availability_zone_hints | | | availability_zones| | | created_at| 2019-06-19T18:01:01Z | | description | | | dns_domain| None | | id| 8961329b-08a2-4c7c-88cf-b5cca43ca678 | | ipv4_address_scope| None | | ipv6_address_scope| None | | is_default| False| | is_vlan_transparent | None | | mtu | 1450 | | name | rbacnet1 | | port_security_enabled | True | | project_id| 4ff7e3db6d64429db1b39f993bb99411 | | provider:network_type | None | | provider:physical_network | None | | provider:segmentation_id | None | | qos_policy_id | None | | revision_number | 2| | router:external | Internal | | segments | None | | shared| False| | status| ACTIVE | | subnets | | | tags | | | updated_at| 2019-06-19T18:01:02Z | +---+--+ user1 (overcloud) [stack@undercloud-0 ~]$ openstack network list +--+--+--+ | ID | Name | Subnets | +--+--+--+ | 8961329b-08a2-4c7c-88cf-b5cca43ca678 | rbacnet1 | | | d6540930-acb2-48f9-8451-da3c5c7622aa | public | 2b59541a-8e12-499f-88d6-7c79c56fcfe9 | +--+--+--+ user1 (overcloud) [stack@undercloud-0 ~]$ openstack network rbac create --type network --action access_as_shared --target-project ba08ccc271614bf1add0902f73690bac rbacnet1 +---+--+ | Field | Value| +---+--+ | action| access_as_shared | | id| e377033b-f374-4fd5-8015-9a7426681d7e | | name | None | | object_id | 8961329b-08a2-4c7c-88cf-b5cca43ca678 | | object_type | network | | project_id| 4ff7e3db6d64429db1b39f993bb99411 | | target_project_id | ba08ccc271614bf1add0902f73690bac | +---+--+ user1 (overcloud) [stack@undercloud-0 ~]$ openstack subnet create --network rbacnet1 --subnet-range 10.0.100.0/24 --dhcp rbacsubnet1 +---+--+ | Field | Value|
[Yahoo-eng-team] [Bug 1833446] [NEW] 5 second delay failing to communicate with OpenStack HTTP endpoint during boot on Oracle Cloud Infrastructure
Public bug reported: The eventual traceback: 2019-06-19 16:27:02,468 - util.py[DEBUG]: Failed fetching meta-data/ from url http://169.254.169.254/latest/meta-data/ Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/ec2_utils.py", line 178, in _get_instance_metadata response = caller(md_url) File "/usr/lib/python3/dist-packages/cloudinit/url_helper.py", line 107, in read_file_or_url exception_cb=exception_cb) File "/usr/lib/python3/dist-packages/cloudinit/url_helper.py", line 306, in readurl raise excps[-1] cloudinit.url_helper.UrlError: 404 Client Error: Not Found for url: http://169.254.169.254/latest/meta-data/ (I can confirm several minutes after instance launch that I still see the same 404 error.) ** Affects: cloud-init Importance: Undecided Status: New ** Tags: oci ** Attachment added: "cloud-init.tar.gz" https://bugs.launchpad.net/bugs/1833446/+attachment/5271601/+files/cloud-init.tar.gz -- 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/1833446 Title: 5 second delay failing to communicate with OpenStack HTTP endpoint during boot on Oracle Cloud Infrastructure Status in cloud-init: New Bug description: The eventual traceback: 2019-06-19 16:27:02,468 - util.py[DEBUG]: Failed fetching meta-data/ from url http://169.254.169.254/latest/meta-data/ Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/ec2_utils.py", line 178, in _get_instance_metadata response = caller(md_url) File "/usr/lib/python3/dist-packages/cloudinit/url_helper.py", line 107, in read_file_or_url exception_cb=exception_cb) File "/usr/lib/python3/dist-packages/cloudinit/url_helper.py", line 306, in readurl raise excps[-1] cloudinit.url_helper.UrlError: 404 Client Error: Not Found for url: http://169.254.169.254/latest/meta-data/ (I can confirm several minutes after instance launch that I still see the same 404 error.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1833446/+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 1833442] [NEW] runcmd commands are not parsed / executed
Public bug reported: Images used from centos.cloud OS version: CentOS 7.2 and 7.5 Cloud-init versions tried with: cloud-init-0.7.9-24.el7.centos.x86_64 cloud-init-18.2-1.el7.centos.2.x86_64 Issue: - adding 90_custom-runcmd.cfg with following content to /etc/cloud/cloud.cfg.d/: runcmd: - [ ip, "-6", route, add, default, via, "::::w", dev, eth0 ] - [ touch, /tmp/file.txt ] File is not parsed, command not executed. Cloud init complains about bad datasource and /var/lib/cloud/instance/scripts/runcmd is not updated. datasource is: datasource_list: ["NoCloud", "ConfigDrive"] We are using cloud-init for initialization of VMs in oVirt. Please assist, I will provide any additional log files if needed. ** Affects: cloud-init Importance: Undecided Status: New -- 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/1833442 Title: runcmd commands are not parsed / executed Status in cloud-init: New Bug description: Images used from centos.cloud OS version: CentOS 7.2 and 7.5 Cloud-init versions tried with: cloud-init-0.7.9-24.el7.centos.x86_64 cloud-init-18.2-1.el7.centos.2.x86_64 Issue: - adding 90_custom-runcmd.cfg with following content to /etc/cloud/cloud.cfg.d/: runcmd: - [ ip, "-6", route, add, default, via, "::::w", dev, eth0 ] - [ touch, /tmp/file.txt ] File is not parsed, command not executed. Cloud init complains about bad datasource and /var/lib/cloud/instance/scripts/runcmd is not updated. datasource is: datasource_list: ["NoCloud", "ConfigDrive"] We are using cloud-init for initialization of VMs in oVirt. Please assist, I will provide any additional log files if needed. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1833442/+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 1833340] Re: Keystone build from source fails on intel
"fatal error: Python.h: No such file or directory" means you need the python2 or python3 development libraries installed, which you can do by installing either the python-dev, python3-dev, python-devel or python3-devel package on your distribution, depending on what version of python you are using and what distro you are using. https://stackoverflow.com/questions/21530577/fatal-error-python-h-no- such-file-or-directory ** Changed in: keystone Status: New => Invalid -- 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/1833340 Title: Keystone build from source fails on intel Status in OpenStack Identity (keystone): Invalid Bug description: Hi team, We are trying to build keystone v15.0.0 from source on intel on sles12-sp4. But when we try to run the pip install command with requirements.txt it fails with the error python.h not found. Error log for pip install is `/crypto -I/usr/local/include -I/usr/include -I/usr/include/python2.7 -c src/scrypt.c -o build/temp.linux- x86_64-2.7/src/scrypt.o -O2 src/scrypt.c:28:20: fatal error: Python.h: No such file or directory #include ^ compilation terminated. error: command 'gcc' failed with exit status 1` Further we executed "sudo tox -egenconfig" command which failed with below error - `ERROR: Could not find a version that satisfies the requirement requests===2.22.0 (from -c https://git.openstack.org/cgit/openstack/requirements/ plain/upper-constraints.txt` Full error log is as below: ```ERROR: Could not find a version that satisfies the requirement requests===2.22.0 (from -c https://git.openstack.org/cgit/openstack/requirements/ plain/upper- constraints.txt (line 245)) (from versions: 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.4.0, 0.4.1, 0.5.0, 0.5.1, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5, 0.6.6, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5, 0.7.6, 0.8.0, 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5 , 0.8.6, 0.8.7, 0.8.8, 0.8.9, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.10.0, 0.10.1, 0.10.2, 0.10.3, 0.10.4, 0.10.6, 0.10.7, 0.10.8, 0.11.1, 0.11.2, 0.12.0, 0.12.1, 0.13.0, 0.13.1, 0.13.2, 0.13.3, 0.13.4, 0.13.5, 0.13.6, 0.13.7, 0.13.8, 0.13.9, 0.14.0, 0.14.1, 0.14.2, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.1.0, 1.2.0, 1.2.1, 1.2.2, 1.2.3, 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0, 2.4.1, 2.4.2, 2.4.3, 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.6.0, 2.6.1 , 2.6.2, 2.7.0, 2.8.0, 2.8.1, 2.9.0, 2.9.1, 2.9.2, 2.10.0, 2.11.0, 2.11.1, 2.12.0, 2.12.1, 2.12.2, 2.12.3, 2.12.4, 2.12.5, 2.13.0, 2.14.0, 2.14.1, 2.14.2, 2.15.1, 2.16.0, 2.16.1, 2.16.2, 2.16.3, 2.16.4, 2.16.5, 2.17.0, 2.17.1, 2.17.2, 2.17.3, 2.18.0, 2.18.1, 2.18.2, 2.18.3, 2.18.4, 2.19.0, 2 .19.1, 2.20.0, 2.20.1, 2.21.0) ERROR: No matching distribution found for requests===2.22.0 (from -c https://git.openstack.org/cgit/openstack/requirements/plain/upper- constraints .txt (line 245)) log end = ERROR: could not install deps [-chttps://git.openstack.org/cgit/openstack/requirements/plain/upper- constraints.txt, -r/home/test/keystone/requirem ents.txt, -r/home/test/keystone/test-requirements.txt, .[ldap,memcache,mongodb]]; v = InvocationError(u"/home/test/keystone/.tox/genconfig/bin/pip install -chttps://git.openstack.org/cgit/openstack/requirements/plain/upper- constraints.txt -r/home/test/keystone/requirements.txt -r/home/test/k eystone/test-requirements.txt '.[ldap,memcache,mongodb]'", 1) summary _ ERROR: genconfig: could not install deps [-chttps://git.openstack.org/cgit/openstack/requirements/plain/upper- constraints.txt, -r/home/test/keys tone/requirements.txt, -r/home/test/keystone/test-requirements.txt, .[ldap,memcache,mongodb]]; v = InvocationError(u"/home/test/keystone/.tox/genc onfig/bin/pip install -chttps://git.openstack.org/cgit/openstack/requirements/plain/upper- constraints.txt -r/home/test/keystone/requirements.txt -``` Please help in fixing this build issue on Intel. Are there any known pointers? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1833340/+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 1818844] Re: Token API doesn't use default roles
Reviewed: https://review.opendev.org/665231 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=092570fc5ef43497c29cf174bfff43323a49fb58 Submitter: Zuul Branch:master commit 092570fc5ef43497c29cf174bfff43323a49fb58 Author: Lance Bragstad Date: Thu Jun 13 20:12:56 2019 + Implement system scope and default roles for token API This commit adds protection testing for the token API along with changes to default policies to properly consume system-scope and default roles. Originally, this work was going to include the ability for project and domain administrator to validate, check, or revoke tokens within the context of their authorization (e.g., a domain administrator could revoke tokens on projects within their domain). This seems like extra work for not much benefit since we're using bearer tokens. The holder of the token can do anything with that token, which means they can validate it or revoke it without using their own token. Adding project and domain administrator support seems unnecessary given the existing functionality. If someone comes forward asking for this functionality, we can re-evaluate the effort. For now, this patch is limited to system user support, allowing them to validate, check, and revoke any token in the system. Service users can still validate tokens on behalf of users. Users can do anything they wish with their own tokens. This commit also bumps the minimum version of oslo.log so that we can use the official TRAIN deprecated release marker. Change-Id: Ia8b35258b43213bd117df4275c907aac223342b3 Closes-Bug: 1818844 Closes-Bug: 1750676 ** Changed in: keystone Status: In Progress => 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/1818844 Title: Token API doesn't use default roles Status in OpenStack Identity (keystone): Fix Released Bug description: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The token API doesn't incorporate these defaults into its default policies [1], but it should. For example, a system reader should be able to validate tokens for other users, but only system administrators should be able to revoke them (since it's technically a writeable API). Building these roles into the token API will make it easier for system users who aren't administrators to diagnose token issues for users. [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html [1] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/token.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1818844/+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 1750676] Re: The v3 token API should account for different scopes
Reviewed: https://review.opendev.org/665231 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=092570fc5ef43497c29cf174bfff43323a49fb58 Submitter: Zuul Branch:master commit 092570fc5ef43497c29cf174bfff43323a49fb58 Author: Lance Bragstad Date: Thu Jun 13 20:12:56 2019 + Implement system scope and default roles for token API This commit adds protection testing for the token API along with changes to default policies to properly consume system-scope and default roles. Originally, this work was going to include the ability for project and domain administrator to validate, check, or revoke tokens within the context of their authorization (e.g., a domain administrator could revoke tokens on projects within their domain). This seems like extra work for not much benefit since we're using bearer tokens. The holder of the token can do anything with that token, which means they can validate it or revoke it without using their own token. Adding project and domain administrator support seems unnecessary given the existing functionality. If someone comes forward asking for this functionality, we can re-evaluate the effort. For now, this patch is limited to system user support, allowing them to validate, check, and revoke any token in the system. Service users can still validate tokens on behalf of users. Users can do anything they wish with their own tokens. This commit also bumps the minimum version of oslo.log so that we can use the official TRAIN deprecated release marker. Change-Id: Ia8b35258b43213bd117df4275c907aac223342b3 Closes-Bug: 1818844 Closes-Bug: 1750676 ** Changed in: keystone Status: In Progress => 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/1750676 Title: The v3 token API should account for different scopes Status in OpenStack Identity (keystone): Fix Released Bug description: Keystone implemented scope_types for oslo.policy RuleDefault objects in the Queens release. In order to take full advantage of scope_types, keystone is going to have to evolve policy enforcement checks in the user API. This is documented in each patch with FIXMEs [0]. The following acceptance criteria describes how the v3 authentication API should behave with tokens from multiple scopes: HEAD /v3/auth/tokens - Someone with a system role assignment that passes the check string should be able to check any token issued from a deployment's keystone (system-scoped) - Someone with a domain role assignment that passes the check string should only be able to check tokens for users that are members of the domain they administer (domain-scoped) - Someone with a project role assignment that passes the check string should only be able to check tokens that are scoped to the project they administer (project-scoped) - Someone with a token should be able to validate the token with itself GET /v3/auth/tokens - Someone with a system role assignment that passes the check string should be able to validate any token issued from a deployment's keystone (system-scoped) - Someone with a domain role assignment that passes the check string should only be able to validate tokens for users that are members of the domain they administer (domain-scoped) - Someone with a project role assignment that passes the check string should only be able to validate tokens that are scoped to the project they administer (project-scoped) - Someone with a token should be able to validate the token with itself DELETE /v3/auth/tokens - Someone with a system role assignment that passes the check string should be able to revoke any token issued by the deployment's keystone (system-scoped) - Someone with a domain role assignment that passes the check string should only be able to revoke tokens scoped to the domain they administer, or projects within that domain (domain-scoped) - Someone with a project role assignment that passes the check string should only be able to revoke tokens scoped to the project they administer (project-scoped) - Any user should be able to invalidate their own token by setting it as the X-Auth-Header and the X-Subject-Header [0] https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/token.py#L21-L32 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1750676/+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 1833178] Re: Horizon LiveMigrate PopUp - Fields too Short to show full Custom name
** Project changed: nova => horizon -- 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/1833178 Title: Horizon LiveMigrate PopUp - Fields too Short to show full Custom name Status in OpenStack Dashboard (Horizon): New Bug description: Description === Horizon LiveMigrate PopUp - Fields too Short to show full Custom name. Neither Current Host nor New Host fields show the full 15Char added custom names (if examples below appears as "espoo---2"), Allowing the user to select the right compute out of the list of available computes. These fields should allow the full context of compute names a user is able to use. I have computes with names such as: overcloud-sriovperformancecompute-espoo---2.localdomain overcloud-ovscompute-espoo---1.localdomain overcloud-dpdkperformancecompute-espoo---1.localdomain Workaround: NA. Customer impact: Major - User can't select the right compute to Live Migrate into. Attached Files: JPG Steps to reproduce == Reproduce: 1:1 (Always) 1. Install setup with maximal Custom host name (15Char) 2. Invoke VM LiveMigrate check presentation of VM Current Host and New Host fields 3. Expected result === 1. All activities can still be performed with full name presented clearly. Actual result = 1. Horizon LiveMigrate PopUp - Fields too Short to show full Custom name Environment === openstack 3.16.2 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1833178/+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 1818823] Re: Missing community image name
Reviewed: https://review.opendev.org/642391
Committed:
https://git.openstack.org/cgit/openstack/horizon/commit/?id=6f807b6b05ea4a9df93ed23111f10a5041377612
Submitter: Zuul
Branch:master
commit 6f807b6b05ea4a9df93ed23111f10a5041377612
Author: Marek
Date: Wed Mar 6 13:40:07 2019 +0100
Adds community image loading for instance index view
This patch adds community image loading to the Instances index view
so that image names may be displayed in this view even for community
images.
Note, that a second image list API call had to be added to achieve
this, because the glance Rest API does not currently support adding
multiple visiblity values to it's GET filters and community images
have to be retrieved explicitly.
Change-Id: I55249de8762e0744b69ff655fcd7a4aeb56ba9d6
Closes-Bug: #1818823
** Changed in: horizon
Status: In Progress => Fix Released
--
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/1818823
Title:
Missing community image name
Status in OpenStack Dashboard (Horizon):
Fix Released
Bug description:
When listing instances in the main instance table, instances launched
from community images have a dash ("-") in the image name cell rather
than the name of the image.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1818823/+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 1833182] Re: Wrong assert methods in unit tests for libvirt driver
Reviewed: https://review.opendev.org/665897 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=c40de761259c88904fa509b0c9d713a9827bd292 Submitter: Zuul Branch:master commit c40de761259c88904fa509b0c9d713a9827bd292 Author: Takashi NATSUME Date: Tue Jun 18 16:39:58 2019 +0900 Fix wrong assert methods Fix wrong assert methods in the unit tests for libvirt driver. Change-Id: I804d504d21953a936a18b76334557fe3ccb97107 Closes-Bug: #1833182 ** Changed in: nova Status: In Progress => Fix Released -- 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/1833182 Title: Wrong assert methods in unit tests for libvirt driver Status in OpenStack Compute (nova): Fix Released Bug description: 'asset_called' should be 'assert_called'. 'asset_called_once' should be 'assert_called_once'. https://opendev.org/openstack/nova/src/commit/a628d2f09a42a0faa5fcb36793e2304de634638e/nova/tests/unit/virt/libvirt/test_driver.py#L10107 https://opendev.org/openstack/nova/src/commit/a628d2f09a42a0faa5fcb36793e2304de634638e/nova/tests/unit/virt/libvirt/test_driver.py#L10126 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1833182/+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 1833385] [NEW] Functional tests are failing due to missing namespace
Public bug reported: Example of failure: http://logs.openstack.org/48/665548/4/check/neutron- functional/f6d6447/testr_results.html.gz But from journal log in this job's results it looks that this missing namespace was existing earlier. So maybe it's some race condition or slow down of node? It has to be checked. ** Affects: neutron Importance: Medium Status: Confirmed ** Tags: functional-tests gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1833385 Title: Functional tests are failing due to missing namespace Status in neutron: Confirmed Bug description: Example of failure: http://logs.openstack.org/48/665548/4/check/neutron- functional/f6d6447/testr_results.html.gz But from journal log in this job's results it looks that this missing namespace was existing earlier. So maybe it's some race condition or slow down of node? It has to be checked. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1833385/+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 1833386] [NEW] Fullstack test neutron.tests.fullstack.test_l3_agent.TestLegacyL3Agent.test_north_south_traffic is failing
Public bug reported: Fullstack test test neutron.tests.fullstack.test_l3_agent.TestLegacyL3Agent.test_north_south_traffic is failing quite often (probably) due to errors in ovs agent. Examples of failure: http://logs.openstack.org/11/662111/21/check/neutron-fullstack/c0f8029/testr_results.html.gz http://logs.openstack.org/29/664629/1/check/neutron-fullstack/e99aa1c/testr_results.html.gz http://logs.openstack.org/12/640812/2/check/neutron-fullstack/21f02c4/testr_results.html.gz In both cases in ovs agent's logs there are errors like: http://logs.openstack.org/11/662111/21/check/neutron-fullstack/c0f8029/controller/logs/dsvm-fullstack-logs/TestLegacyL3Agent.test_north_south_traffic/neutron-openvswitch-agent--2019-06-18--01-52-58-123455_log.txt.gz?level=ERROR Logstash query: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22neutron.tests.fullstack.test_l3_agent.TestLegacyL3Agent.test_north_south_traffic%20%5C%22%20AND%20message%3A%5C%22...%20FAILED%5C%22 ** Affects: neutron Importance: High Status: Confirmed ** Tags: fullstack gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1833386 Title: Fullstack test neutron.tests.fullstack.test_l3_agent.TestLegacyL3Agent.test_north_south_traffic is failing Status in neutron: Confirmed Bug description: Fullstack test test neutron.tests.fullstack.test_l3_agent.TestLegacyL3Agent.test_north_south_traffic is failing quite often (probably) due to errors in ovs agent. Examples of failure: http://logs.openstack.org/11/662111/21/check/neutron-fullstack/c0f8029/testr_results.html.gz http://logs.openstack.org/29/664629/1/check/neutron-fullstack/e99aa1c/testr_results.html.gz http://logs.openstack.org/12/640812/2/check/neutron-fullstack/21f02c4/testr_results.html.gz In both cases in ovs agent's logs there are errors like: http://logs.openstack.org/11/662111/21/check/neutron-fullstack/c0f8029/controller/logs/dsvm-fullstack-logs/TestLegacyL3Agent.test_north_south_traffic/neutron-openvswitch-agent--2019-06-18--01-52-58-123455_log.txt.gz?level=ERROR Logstash query: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22neutron.tests.fullstack.test_l3_agent.TestLegacyL3Agent.test_north_south_traffic%20%5C%22%20AND%20message%3A%5C%22...%20FAILED%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1833386/+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 1833374] [NEW] Default behavior is not consistent while creating FWaaS-v2 group through Horizon Dashboard and through CLI command.
Public bug reported: Description: Creating Firewall Group through openstack CLI command set the admin state to true please find the below command, but through Horizon Dashboard Admin state is set to "False" by default. [root@vioshim-l42jp6xt7m-vioshim-84bb866c4d-lw6wj /]# openstack firewall group create --name F9 +---+--+ | Field | Value| +---+--+ | Description | | | Egress Policy ID | None | | ID| b16bbdd5-ba11-475a-b74a-acf27b3667ac | | Ingress Policy ID | None | | Name | F9 | | Ports | [] | | Project | 52e5cd63615243cd9439952c5214d0f7 | | Shared| False| | State | UP | | Status| INACTIVE | | project_id| 52e5cd63615243cd9439952c5214d0f7 | +---+--+ Expected: Dafault behavior should be consistent whether the Firewall group created using Horizon or through the neutron cLi command. ** Affects: neutron-fwaas-dashboard Importance: Undecided Status: New ** Project changed: neutron => neutron-fwaas-dashboard ** Description changed: - Description: Creating Firewall Group through openstack CLI command - please find the below command, but through Horizon Dashboard Admin - state is set to "False" by default - + Description: Creating Firewall Group through openstack CLI command set + the admin state to true please find the below command, but through + Horizon Dashboard Admin state is set to "False" by default. [root@vioshim-l42jp6xt7m-vioshim-84bb866c4d-lw6wj /]# openstack firewall group create --name F9 +---+--+ | Field | Value| +---+--+ | Description | | | Egress Policy ID | None | | ID| b16bbdd5-ba11-475a-b74a-acf27b3667ac | | Ingress Policy ID | None | | Name | F9 | | Ports | [] | | Project | 52e5cd63615243cd9439952c5214d0f7 | | Shared| False| | State | UP | | Status| INACTIVE | | project_id| 52e5cd63615243cd9439952c5214d0f7 | +---+--+ - - Expected: Dafault behavior should be consistent whether the Firewall group created using Horizon or through the neutron cLi command. + Expected: Dafault behavior should be consistent whether the Firewall + group created using Horizon or through the neutron cLi command. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1833374 Title: Default behavior is not consistent while creating FWaaS-v2 group through Horizon Dashboard and through CLI command. Status in Neutron FWaaS dashboard: New Bug description: Description: Creating Firewall Group through openstack CLI command set the admin state to true please find the below command, but through Horizon Dashboard Admin state is set to "False" by default. [root@vioshim-l42jp6xt7m-vioshim-84bb866c4d-lw6wj /]# openstack firewall group create --name F9 +---+--+ | Field | Value| +---+--+ | Description | | | Egress Policy ID | None | | ID| b16bbdd5-ba11-475a-b74a-acf27b3667ac | | Ingress Policy ID | None | | Name | F9 | | Ports | [] | | Project | 52e5cd63615243cd9439952c5214d0f7 | | Shared| False| | State | UP | | Status| INACTIVE | | project_id| 52e5cd63615243cd9439952c5214d0f7 | +---+--+ Expected: Dafault behavior should be consistent whether the Firewall group created using Horizon or through the neutron cLi
[Yahoo-eng-team] [Bug 1832288] Re: The asterisk mark color and location are inconsistent in the Create Key Pair and Import Key Form
Reviewed: https://review.opendev.org/664486 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=cbd15bf910da3faf737b7669467afa310d2da676 Submitter: Zuul Branch:master commit cbd15bf910da3faf737b7669467afa310d2da676 Author: pengyuesheng Date: Tue Jun 11 10:04:41 2019 +0800 Uniform asterisk mark color and location The asterisk mark color and location are inconsistent in the Create Key Pair and Import Key Form. This Patch uniform asterisk mark color and location in some forms Change-Id: Ia55db622b35005e9da4ff83f39414a37ddc19e87 Closes-Bug: #1832288 ** Changed in: horizon Status: In Progress => Fix Released -- 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/1832288 Title: The asterisk mark color and location are inconsistent in the Create Key Pair and Import Key Form Status in OpenStack Dashboard (Horizon): Fix Released Bug description: The asterisk mark color and location are inconsistent in the Create Key Pair and Import Key Form To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1832288/+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
