[Yahoo-eng-team] [Bug 1825295] Re: The openflow won't be deleted when we reboot and migrate the instance
The bug was resolved in the last version, but not a indirect way, it was fixed because of self.plugin_rpc.register_legacy_notification_callbacks, in this function it will notify the local agent to update the port again, so the port will be handle twice, the second update will refresh firewall rule, and write the port to sg_port_map. The get_or_create_ofport still remove the port from sg_port_map, and not added it back, perhaps it will be a hidden bug for some other situations. ** Changed in: neutron Status: Invalid => New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1825295 Title: The openflow won't be deleted when we reboot and migrate the instance Status in neutron: New Bug description: Sometimes user will do some steps for instance management: 1. Restart hostA neutron-openvswitch-agent 2. Reboot the instance which in hostA 3. Migrate the instance from hostA to hostB or resize the instance(this also cause migration) Then we will find the instance's openflows on the hostA still exist, this will cause instance connectivity problem. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1825295/+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 1824346] Re: Check in "_update_segmentation_id" that the mech_driver has an agent
Reviewed: https://review.opendev.org/651878 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=749b33e41bc905a3bec9d356c78a477e9b8aa87d Submitter: Zuul Branch:master commit 749b33e41bc905a3bec9d356c78a477e9b8aa87d Author: Rodolfo Alonso Hernandez Date: Thu Apr 11 12:49:20 2019 + Check in "_update_segmentation_id" that the mech_driver has an agent In [1] it is assumed that all mechanism drivers have an agent, but the mech driver API [2] doesn't enforce it. VIF types will be retrieved only from those mechanism drivers with an associated agent. [1]https://review.openstack.org/#/c/633165/20/neutron/plugins/ml2/plugin.py@814 [2]https://github.com/openstack/neutron-lib/blob/stable/stein/neutron_lib/plugins/ml2/api.py#L37 Change-Id: I5c334f31259871ed5251d5d4a2ba8cae36bd2355 Closes-Bug: #1824346 ** Changed in: neutron 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/1824346 Title: Check in "_update_segmentation_id" that the mech_driver has an agent Status in neutron: Fix Released Bug description: In [1] it is assumed that all mechanism drivers have an agent, but the mech driver API [2] doesn't enforce it. An additional check must be done in order to retrieve the "agent_type" instance variable. [1] https://review.openstack.org/#/c/633165/20/neutron/plugins/ml2/plugin.py@814 [2] https://github.com/openstack/neutron-lib/blob/stable/stein/neutron_lib/plugins/ml2/api.py#L37 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1824346/+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 1826267] [NEW] Disassociate is spelled incorrectly on the button to disassociate a floating ip address.
Public bug reported: Running horizon 14 on Openstack Rocky the "disassociate" button under the disassociate floating IP menu is miss-spelled as disassocaite ** 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/1826267 Title: Disassociate is spelled incorrectly on the button to disassociate a floating ip address. Status in OpenStack Dashboard (Horizon): New Bug description: Running horizon 14 on Openstack Rocky the "disassociate" button under the disassociate floating IP menu is miss-spelled as disassocaite To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1826267/+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 1792077] Re: problem specifying multiple "bus=scsi" block devices on nova boot
** No longer affects: nova/ocata -- 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/1792077 Title: problem specifying multiple "bus=scsi" block devices on nova boot Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) pike series: Fix Committed Status in OpenStack Compute (nova) queens series: Fix Committed Status in OpenStack Compute (nova) rocky series: Fix Committed Status in OpenStack Compute (nova) stein series: Fix Committed Bug description: I'm using devstack stable/rocky on ubuntu 16.04. When running this command nova boot --flavor m1.small --nic net-name=public --block-device source=image,id=24e8e922-2687-48b5-a895-3134a650e00f,dest=volume,size=2,bootindex=0,shutdown=remove,bus=scsi --block-device source=blank,dest=volume,size=2,bootindex=1,shutdown=remove,bus=scsi --poll twovol the instance fails to boot with the error: libvirtError: unsupported configuration: Found duplicate drive address for disk with target name 'sda' controller='0' bus='0' target='0' unit='0' For some background information, this works: nova boot --flavor m1.small --nic net-name=public --block-device source=image,id=24e8e922-2687-48b5-a895-3134a650e00f,dest=volume,size=2,bootindex=0,shutdown=remove,bus=scsi --poll onevol It also works if I have two block devices but don't specify "bus=scsi": nova boot --flavor m1.small --nic net-name=public --block-device source=image,id=24e8e922-2687-48b5-a895-3134a650e00f,dest=volume,size=2,bootindex=0,shutdown=remove --block-device source=blank,dest=volume,size=2,bootindex=1,shutdown=remove --poll twovolnoscsi This maps to the following XML: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: f16cb93d-7bf0-4da7-a804-b9539d64576a Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: 7d5de2b0-cb66-4607-a5f5-60fd40db51c3 Sep 12 05:05:22 devstack nova-compute[3062]: In the failure case, the nova-compute logs include the following interesting bits. Note the additional '' lines in the XML. Sep 12 04:48:43 devstack nova-compute[3062]: ERROR nova.virt.libvirt.guest [None req-a7c5f15c-1e44-4cd1-bf57-45b819676b20 admin admin] Error defining a guest with XML: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: 08561cc0-5cf2-4eb7-a3f9-956f945e6c24 Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: 007fac3d-8800-4f45-9531-e3bab5c86a1e Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: : libvirtError: unsupported configuration: Found duplicate drive address for disk with target name 'sda' controller='0' bus='0' target='0' unit='0' Sep 12 04:48:43 devstack nova-compute[3062]: ERROR nova.virt.libvirt.driver [None req-a7c5f15c-1e44-4cd1-bf57-45b819676b20 admin admin] [instance: cf4f2c6f-7391-4a49-8f40-5e5cda98f78b] Failed to start libvirt guest: libvirtError: unsupported configuration: Found duplicate drive address for disk with target name 'sda' controller='0' bus='0' target='0' unit='0' Here is the libvirtd log in the failure case: 2018-09-12 04:48:43.312+: 16889: error : virDomainDefCheckDuplicateDriveAddresses:5747 : unsupported configuration: Found duplicate drive address for disk with target name 'sda' controller='0' bus='0' target='0' unit='0' To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1792077/+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 1784093] Re: Build requests can be orphaned without instance mappings
** Also affects: nova/rocky Importance: Undecided Status: New ** Also affects: nova/queens Importance: Undecided Status: New ** Also affects: nova/stein Importance: Undecided Status: New ** Changed in: nova/stein Importance: Undecided => Medium ** Changed in: nova/rocky Importance: Undecided => Medium ** Changed in: nova/queens Importance: Undecided => Medium -- 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/1784093 Title: Build requests can be orphaned without instance mappings Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) queens series: New Status in OpenStack Compute (nova) rocky series: New Status in OpenStack Compute (nova) stein series: New Bug description: Mohammed reported this in the nova channel today [1] and the RDO cloud people have run into the same issue too. The deployment got into a situation where instances would show up in a 'nova list' in BUILD/scheduling state but were unable to be deleted. (They show up in 'nova list' because 'nova list' lists build requests and all instances in all cells). Inspection of the database showed that the "instance" had a build request but *no* instance mapping and *no* instance record in any cell. And the instance could not be deleted even though it appeared in the 'nova list' because the delete API first does a compute API().get in order to get the instance object to pass down to the compute API().delete method. The compute API().get fails with InstanceNotFound because the _get_instance method raises InstanceNotFound if there is no instance mapping for the instance. Mohammed was able to share this trace [2] which shows the instance_mapping.create() failing due to database errors, right after the build_request.create() succeeded: 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/openstack/venvs/nova-17.0.3/lib/python2.7/site-packages/nova/compute/api.py", line 937, in _provision_instances 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi inst_mapping.create() 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/openstack/venvs/nova-17.0.3/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line 226, in wrapper 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi return fn(self, *args, **kwargs) 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/openstack/venvs/nova-17.0.3/lib/python2.7/site-packages/nova/objects/instance_mapping.py", line 92, in create 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi db_mapping = self._create_in_db(self._context, changes) 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/openstack/venvs/nova-17.0.3/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", line 986, in wrapper 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi return fn(*args, **kwargs) 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__ 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi self.gen.next() 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/openstack/venvs/nova-17.0.3/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", line 1036, in _transaction_scope 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi yield resource 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__ 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi self.gen.next() 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/openstack/venvs/nova-17.0.3/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", line 646, in _session 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi self.session.rollback() 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/openstack/venvs/nova-17.0.3/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 907, in rollback 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi self.transaction.rollback() 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/openstack/venvs/nova-17.0.3/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 532, in rollback 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi util.reraise(*rollback_err) 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File "/openstack/venvs/nova-17.0.3/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 497, in rollback 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi t[1].rollback() 2018-07-25 04:20:12.946 7926 ERROR nova.api.openstack.wsgi File
[Yahoo-eng-team] [Bug 1823155] Re: neutron-fullstack fails on stable/rocky at ovs compilation
Backport merged up to Pike (and Ocata has W+1, pending recheck), we can consider this one fixed ** Changed in: neutron Status: Confirmed => 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/1823155 Title: neutron-fullstack fails on stable/rocky at ovs compilation Status in neutron: Fix Released Bug description: A recent behaviour, fullstack now fails on rocky branch in ovs compilation (nf_conntrack_reasm.c file): /opt/stack/new/ovs/datapath/linux/nf_conntrack_reasm.c:105:31: error: ‘struct inet_frags’ has no member named ‘rnd’ /opt/stack/new/ovs/datapath/linux/nf_conntrack_reasm.c:320:2: error: too many arguments to function ‘inet_frag_kill’ and some other errors. Sample logs: http://logs.openstack.org/43/649043/3/check/neutron-fullstack/2310d39/job-output.txt.gz#_2019-04-04_07_45_21_538707 http://logs.openstack.org/40/649540/2/check/neutron-fullstack/77cf080/job-output.txt.gz#_2019-04-04_07_15_54_376644 failing on recent reviews: https://review.openstack.org/#/c/649043/ https://review.openstack.org/#/c/649540/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1823155/+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 1826186] [NEW] port list / get_ports() fails when filtering and limiting at the same time
Public bug reported:
When doing a openstack port list that filters for a fixed-ip/subnet and
at the same time limits the amount of results neutron returns a 500
internal server error.
Example command: openstack port list --fixed-ip ip-address=192.0.2.23
Limits should be applied automatically with a recent version of the
openstacksdk with pagination turned on by default. Additionally, I attached a
testcase that triggers this bug. This bug was found on neutron-queens, but the
test-case also breaks current master (tested on commit id
1214e59cc2d818f6fde9c3e24c7f26c50d2a8a74).
It looks like _get_ports_query() gets a query with pre-applied limits by
calling model_query.get_collection_query() and then tries to filter the
results, which triggers a sqlalchemy assertion that disallows filtering
after a limit has been applied.
The corresponding exception neutron exception would be the following:
InvalidRequestError: Query.filter() being called on a Query which already has
LIMIT or OFFSET applied. To modify the row-limited results of a Query, call
from_self() first. Otherwise, call filter() before limit() or offset() are
applied.
File "pecan/core.py", line 683, in __call__
self.invoke_controller(controller, args, kwargs, state)
File "pecan/core.py", line 574, in invoke_controller
result = controller(*args, **kwargs)
File "neutron/db/api.py", line 91, in wrapped
setattr(e, '_RETRY_EXCEEDED', True)
File "oslo_utils/excutils.py", line 220, in __exit__
self.force_reraise()
File "oslo_utils/excutils.py", line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File "neutron/db/api.py", line 87, in wrapped
return f(*args, **kwargs)
File "oslo_db/api.py", line 147, in wrapper
ectxt.value = e.inner_exc
File "oslo_utils/excutils.py", line 220, in __exit__
self.force_reraise()
File "oslo_utils/excutils.py", line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File "oslo_db/api.py", line 135, in wrapper
return f(*args, **kwargs)
File "neutron/db/api.py", line 126, in wrapped
LOG.debug("Retry wrapper got retriable exception: %s", e)
File "oslo_utils/excutils.py", line 220, in __exit__
self.force_reraise()
File "oslo_utils/excutils.py", line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File "neutron/db/api.py", line 122, in wrapped
return f(*dup_args, **dup_kwargs)
File "neutron/pecan_wsgi/controllers/utils.py", line 76, in wrapped
return f(*args, **kwargs)
File "neutron/pecan_wsgi/controllers/resource.py", line 131, in index
return self.get(*args, **kwargs)
File "neutron/pecan_wsgi/controllers/resource.py", line 141, in get
**query_params)}
File "neutron/db/api.py", line 161, in wrapped
return method(*args, **kwargs)
File "neutron/db/api.py", line 91, in wrapped
setattr(e, '_RETRY_EXCEEDED', True)
File "oslo_utils/excutils.py", line 220, in __exit__
self.force_reraise()
File "oslo_utils/excutils.py", line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File "neutron/db/api.py", line 87, in wrapped
return f(*args, **kwargs)
File "oslo_db/api.py", line 147, in wrapper
ectxt.value = e.inner_exc
File "oslo_utils/excutils.py", line 220, in __exit__
self.force_reraise()
File "oslo_utils/excutils.py", line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File "oslo_db/api.py", line 135, in wrapper
return f(*args, **kwargs)
File "neutron/db/api.py", line 126, in wrapped
LOG.debug("Retry wrapper got retriable exception: %s", e)
File "oslo_utils/excutils.py", line 220, in __exit__
self.force_reraise()
File "oslo_utils/excutils.py", line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File "neutron/db/api.py", line 122, in wrapped
return f(*dup_args, **dup_kwargs)
File "neutron/db/db_base_plugin_v2.py", line 1417, in get_ports
page_reverse=page_reverse)
File "neutron/plugins/ml2/plugin.py", line 1941, in _get_ports_query
query = query.filter(substr_filter)
File "", line 2, in filter
File "sqlalchemy/orm/base.py", line 200, in generate
assertion(self, fn.__name__)
File "sqlalchemy/orm/query.py", line 435, in _no_limit_offset
% (meth, meth)
** Affects: neutron
Importance: Undecided
Status: New
** Patch added: "neutron testcase for filtering and limiting on a get ports at
the same time"
https://bugs.launchpad.net/bugs/1826186/+attachment/5258554/+files/test_list_ports_filtered_by_fixed_ip_with_limit.patch
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1826186
Title:
port list / get_ports() fails when filtering and limiting at the same
time
Status in neutron:
New
Bug description:
When doing a openstack port list that filters for a fixed-ip/subnet
and at the same time limits
[Yahoo-eng-team] [Bug 1826156] [NEW] Group Name is optional parameter to create Volume Group
Public bug reported: On Horizon dashboard, the field of "Volume Group name" is marked mandatory in the process of creating new volume group but volume group name is optional parameter while creating group volume using CLI. Proposal: change the field of "Volume Group name" on Horizon dashboard from mandatory to optional. This is supported by the fact that Horizon dashboard displays the group volume's ID for the group volume's name if its name is None or empty ** 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/1826156 Title: Group Name is optional parameter to create Volume Group Status in OpenStack Dashboard (Horizon): New Bug description: On Horizon dashboard, the field of "Volume Group name" is marked mandatory in the process of creating new volume group but volume group name is optional parameter while creating group volume using CLI. Proposal: change the field of "Volume Group name" on Horizon dashboard from mandatory to optional. This is supported by the fact that Horizon dashboard displays the group volume's ID for the group volume's name if its name is None or empty To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1826156/+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 1826136] [NEW] powervm as hypervisor type required for image metadata prefiltering
Public bug reported: "powervm" as hypervisor type is required for image metadata prefiltering in https://github.com/openstack/glance/blob/master/etc/metadefs/compute- hypervisor.json. More about image metadata prefiltering here: http://specs.openstack.org/openstack/nova-specs/specs/train/approved /image-metadata-prefiltering.html. IRC link for the discussion: http://eavesdrop.openstack.org/irclogs /%23openstack-powervm/%23openstack- powervm.2019-04-12.log.html#t2019-04-12T15:06:31 ** Affects: glance Importance: Undecided Assignee: Ankit Arora (aarora06) Status: In Progress ** Tags: glance powervm ** Changed in: tempest Assignee: (unassigned) => Ankit Arora (aarora06) ** Project changed: tempest => glance -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1826136 Title: powervm as hypervisor type required for image metadata prefiltering Status in Glance: In Progress Bug description: "powervm" as hypervisor type is required for image metadata prefiltering in https://github.com/openstack/glance/blob/master/etc/metadefs/compute- hypervisor.json. More about image metadata prefiltering here: http://specs.openstack.org/openstack/nova-specs/specs/train/approved /image-metadata-prefiltering.html. IRC link for the discussion: http://eavesdrop.openstack.org/irclogs /%23openstack-powervm/%23openstack- powervm.2019-04-12.log.html#t2019-04-12T15:06:31 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1826136/+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 1826136] [NEW] powervm as hypervisor type required for image metadata prefiltering
You have been subscribed to a public bug: "powervm" as hypervisor type is required for image metadata prefiltering in https://github.com/openstack/glance/blob/master/etc/metadefs/compute- hypervisor.json. More about image metadata prefiltering here: http://specs.openstack.org/openstack/nova-specs/specs/train/approved /image-metadata-prefiltering.html. IRC link for the discussion: http://eavesdrop.openstack.org/irclogs /%23openstack-powervm/%23openstack- powervm.2019-04-12.log.html#t2019-04-12T15:06:31 ** Affects: glance Importance: Undecided Assignee: Ankit Arora (aarora06) Status: New ** Tags: glance powervm -- powervm as hypervisor type required for image metadata prefiltering https://bugs.launchpad.net/bugs/1826136 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. -- 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 1826120] [NEW] When the network and qos policy are not selected, create RBAC policy would shown error.
Public bug reported: When the network and qos policy are not selected, create RBAC policy would shown error. ** Affects: horizon Importance: Undecided Assignee: pengyuesheng (pengyuesheng) Status: In Progress ** Changed in: horizon Assignee: (unassigned) => pengyuesheng (pengyuesheng) -- 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/1826120 Title: When the network and qos policy are not selected, create RBAC policy would shown error. Status in OpenStack Dashboard (Horizon): In Progress Bug description: When the network and qos policy are not selected, create RBAC policy would shown error. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1826120/+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 1826114] [NEW] Errors creating users and projects
Public bug reported: After a fresh install of OpenStack Stein using Juju Charms I'm getting errors and items not appearing when creating new users and projects. Here are several tests I made: When creating ONLY a new user in a domain different than admin_domain, the user creates successfully but is not shown in the user list on the GUI even after a refresh/logout. Using the CLI shows that it was created successfully. When creating ONLY a project in a domain different than admin_domain, the project creates successfully but is not shown in the user list on the GUI even after a refresh/logout. Using the CLI shows that it was created successfully. When creating a user in a domain different than admin_domain, the project list in the form is empty. When creating a user AND a project in any domain (using the "+" icon in the user creation form), after creating the project the GIU hangs on a "Working..." spinning wheel and the following error appears on the web console: Uncaught SyntaxError: Unexpected token < in JSON at position 53 at JSON.parse () at Function.jQuery.parseJSON (439e79e74c16.js:567) at Function.jQuery.parseJSON (439e79e74c16.js:720) at processServerSuccess (c1b8ea0c3a19.js:80) at Object.success (c1b8ea0c3a19.js:84) at fire (439e79e74c16.js:210) at Object.fireWith [as resolveWith] (439e79e74c16.js:216) at done (439e79e74c16.js:626) at XMLHttpRequest.callback (439e79e74c16.js:653) After a refresh, the project is created but not the user. When creating a new user and a project separately in admin_domain everything works OK. After that I can see both and assign the project to the user. In all the pages I load from Horizon I get the following warning on the web console: 439e79e74c16.js:700 JQMIGRATE: $(html) HTML strings must start with '<' character migrateWarn @ 439e79e74c16.js:700 jQuery.fn.init @ 439e79e74c16.js:714 jQuery @ 439e79e74c16.js:15 success @ c1b8ea0c3a19.js:204 fire @ 439e79e74c16.js:210 fireWith @ 439e79e74c16.js:216 done @ 439e79e74c16.js:626 callback @ 439e79e74c16.js:653 439e79e74c16.js:700 console.trace migrateWarn @ 439e79e74c16.js:700 jQuery.fn.init @ 439e79e74c16.js:714 jQuery @ 439e79e74c16.js:15 success @ c1b8ea0c3a19.js:204 fire @ 439e79e74c16.js:210 fireWith @ 439e79e74c16.js:216 done @ 439e79e74c16.js:626 callback @ 439e79e74c16.js:653 ** 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/1826114 Title: Errors creating users and projects Status in OpenStack Dashboard (Horizon): New Bug description: After a fresh install of OpenStack Stein using Juju Charms I'm getting errors and items not appearing when creating new users and projects. Here are several tests I made: When creating ONLY a new user in a domain different than admin_domain, the user creates successfully but is not shown in the user list on the GUI even after a refresh/logout. Using the CLI shows that it was created successfully. When creating ONLY a project in a domain different than admin_domain, the project creates successfully but is not shown in the user list on the GUI even after a refresh/logout. Using the CLI shows that it was created successfully. When creating a user in a domain different than admin_domain, the project list in the form is empty. When creating a user AND a project in any domain (using the "+" icon in the user creation form), after creating the project the GIU hangs on a "Working..." spinning wheel and the following error appears on the web console: Uncaught SyntaxError: Unexpected token < in JSON at position 53 at JSON.parse () at Function.jQuery.parseJSON (439e79e74c16.js:567) at Function.jQuery.parseJSON (439e79e74c16.js:720) at processServerSuccess (c1b8ea0c3a19.js:80) at Object.success (c1b8ea0c3a19.js:84) at fire (439e79e74c16.js:210) at Object.fireWith [as resolveWith] (439e79e74c16.js:216) at done (439e79e74c16.js:626) at XMLHttpRequest.callback (439e79e74c16.js:653) After a refresh, the project is created but not the user. When creating a new user and a project separately in admin_domain everything works OK. After that I can see both and assign the project to the user. In all the pages I load from Horizon I get the following warning on the web console: 439e79e74c16.js:700 JQMIGRATE: $(html) HTML strings must start with '<' character migrateWarn @ 439e79e74c16.js:700 jQuery.fn.init @ 439e79e74c16.js:714 jQuery @ 439e79e74c16.js:15 success @ c1b8ea0c3a19.js:204 fire @ 439e79e74c16.js:210 fireWith @ 439e79e74c16.js:216 done @ 439e79e74c16.js:626 callback @ 439e79e74c16.js:653 439e79e74c16.js:700 console.trace migrateWarn @ 439e79e74c16.js:700 jQuery.fn.init @ 439e79e74c16.js:714 jQuery @
