[Yahoo-eng-team] [Bug 1875761] [NEW] Verify operation in glance
Public bug reported: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: At "4. Confirm upload of the image and validate attributes:", the command shown is "glance image-list", but the output shown below it is from "openstack image list". - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: on 2020-01-28 06:54:43 SHA: 0a0a39aa83cd64128e42be50983af52914595f2b Source: https://opendev.org/openstack/glance/src/doc/source/install/verify.rst URL: https://docs.openstack.org/glance/train/install/verify.html ** Affects: glance Importance: Undecided Status: New ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1875761 Title: Verify operation in glance Status in Glance: New Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: At "4. Confirm upload of the image and validate attributes:", the command shown is "glance image-list", but the output shown below it is from "openstack image list". - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: on 2020-01-28 06:54:43 SHA: 0a0a39aa83cd64128e42be50983af52914595f2b Source: https://opendev.org/openstack/glance/src/doc/source/install/verify.rst URL: https://docs.openstack.org/glance/train/install/verify.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875761/+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 1875630] Re: issue OSSN when glance no longer requires an md5 implementation
** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1875630 Title: issue OSSN when glance no longer requires an md5 implementation Status in Glance: Triaged Status in OpenStack Security Notes: New Bug description: See https://bugs.launchpad.net/glance/+bug/1875439 for background. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875630/+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 1875418] Re: Generated policy.json in Ussuri is broken by default
That is correct what you wrote above. But tricky part here is generated policy.json from 'oslopolicy-sample-generator' tool without deprecated rules is right thing or wrong. Because it can be seen as one of the valid usgae for deployer who want to switch to new defaults. The only way for them till ussuri(till we introduced new flag in oslo) is to overwrite the policy file with new default (which is what 'oslopolicy- sample-generator 'generate). If we add arg option in 'oslopolicy-sample-generator ' to add a deprecated rule (say --add-deprecated-rules) that also should not be default and deployer need to change the usage of that tool to pass the new arg. Opinion ? also other challenge is we need to check with Oslo team if that can be done now for ussuri. adding oslo also as an affected project. Also, what we are missing here is this bug actually - https://bugs.launchpad.net/oslo.policy/+bug/1853170 ** Also affects: oslo.policy Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1875418 Title: Generated policy.json in Ussuri is broken by default Status in OpenStack Compute (nova): In Progress Status in oslo.policy: New Bug description: Looks like the generated policy.json is broken by default and can't be used by operators as-is, as it doesn't include the deprecated options which are unfortunately needed for it to work. With the default policy.json as generated by the nova namespace, the admin user can't even do simple things like: - openstack flavor create - openstack hypervisor list and probably many more... To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1875418/+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 1780225] Re: Libvirt error when using --max > 1 with vGPU
In Stein, we merged the ability to have multiple Resource Providers, each of them being a pGPU. In Ussuri, we accepted to have a specific vGPU type per pGPU. Now, I tested the above behaviour with https://review.opendev.org/723858 and it works now, unless you ask for a specific total capacity. I'll close this bug that was only for libvirt vGPUs and please look at https://bugs.launchpad.net/nova/+bug/1874664 for the related issue. ** Changed in: nova Status: Confirmed => 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/1780225 Title: Libvirt error when using --max > 1 with vGPU Status in OpenStack Compute (nova): Fix Released Bug description: Description === Using devstack Rocky with a NVIDIA Tesla M10 + GRID driver on RHEL 7.5. Profile used in nova: nvidia-35 (num_heads=2, frl_config=45, framebuffer=512M, max_resolution=2560x1600, max_instance=16) I can launch instances one by one without any issue. I cannot use --max paramater greater than 1. Expected result === Be able to use --max parameter with vGPU Steps to reproduce == [root@host2 ~]# openstack server list +--+---++-+++ | ID | Name | Status | Networks | Image | Flavor | +--+---++-+++ | 56aeda96-f193-49fc-914d-8b507674eb16 | instance0 | ACTIVE | private=fda2:f16f:605e:0:f816:3eff:fef2:8e20, 10.0.0.12, 172.24.4.2 | rhel75 | vgpu | +--+---++-+++ [root@host2 ~]# openstack server create --flavor vgpu --image rhel75 --key-name myself --max 2 instance +-+---+ | Field | Value | +-+---+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | | | OS-EXT-SRV-ATTR:host| None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at| None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | iNiFmD6kNszw | | config_drive| | | created | 2018-07-05T09:19:25Z | | flavor | vgpu (vgpu1) | | hostId | | | id | 5a8691a8-a18c-4c71-8541-be00f224fd82 | | image | rhel75 (e63a49a8-4568-4b57-9d12-1eb1ede28438) | | key_name| myself | | name| instance-1 | | progress| 0 | | project_id | fdea2c781db74ae593c5e9501e9290cc | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2018-07-05T09:19:25Z |
[Yahoo-eng-team] [Bug 1875629] [NEW] api-ref needs update about 'checksum' image property
Public bug reported: A value for the 'checksum' image property will no longer be computed from Victoria onwards. The field itself will remain (so no change in the API response). Current text is: Hash that is used over the image data. The Image service uses this value for verification. The value might be null (JSON null data type). Should change to something like: An MD5 hash over the image data. The value might be null (JSON null data type), as this field is no longer populated by the Image Service beginning with the Victoria release. It remains present for backward compatibility with legacy images. To validate image data, instead use the secure multihash fields ``os_hash_algo`` and ``os_hash_value``. ** Affects: glance Importance: Medium Status: Triaged ** Tags: documentation low-hanging-fruit -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1875629 Title: api-ref needs update about 'checksum' image property Status in Glance: Triaged Bug description: A value for the 'checksum' image property will no longer be computed from Victoria onwards. The field itself will remain (so no change in the API response). Current text is: Hash that is used over the image data. The Image service uses this value for verification. The value might be null (JSON null data type). Should change to something like: An MD5 hash over the image data. The value might be null (JSON null data type), as this field is no longer populated by the Image Service beginning with the Victoria release. It remains present for backward compatibility with legacy images. To validate image data, instead use the secure multihash fields ``os_hash_algo`` and ``os_hash_value``. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875629/+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 1875630] [NEW] issue OSSN when glance no longer requires an md5 implementation
Public bug reported: See https://bugs.launchpad.net/glance/+bug/1875439 for background. ** Affects: glance Importance: Medium Status: Triaged ** Tags: documentation security ** Changed in: glance Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1875630 Title: issue OSSN when glance no longer requires an md5 implementation Status in Glance: Triaged Bug description: See https://bugs.launchpad.net/glance/+bug/1875439 for background. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875630/+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 1875624] [NEW] the vms can not be force deleted when vm_status is soft-delete and task-state=deleting
Public bug reported: Description === the vms can not be force deleted when vm_status is soft-delete and task-state=deleting Steps to reproduce == 1.soft delete the vms 2.force delete the vms which status is soft-delete. 3.down the nova-compute while deleting the vms. 4.restart the nova-compute 5.force delete the vms Expected result === the vms be destoried compeletely Actual result = can not destory these vms. Environment === 1. OpenStack Rocky version 2.Hypervisor is kvm 3.The storage is Ceph 4.Networking is Neutron with OpenVSwitch Logs&Configs The logs as following: Instance is already in deleting state, ignoring this request ** Affects: nova Importance: Undecided Assignee: xuyuanhao (thourch) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1875624 Title: the vms can not be force deleted when vm_status is soft-delete and task-state=deleting Status in OpenStack Compute (nova): New Bug description: Description === the vms can not be force deleted when vm_status is soft-delete and task-state=deleting Steps to reproduce == 1.soft delete the vms 2.force delete the vms which status is soft-delete. 3.down the nova-compute while deleting the vms. 4.restart the nova-compute 5.force delete the vms Expected result === the vms be destoried compeletely Actual result = can not destory these vms. Environment === 1. OpenStack Rocky version 2.Hypervisor is kvm 3.The storage is Ceph 4.Networking is Neutron with OpenVSwitch Logs&Configs The logs as following: Instance is already in deleting state, ignoring this request To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1875624/+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 1657182] Re: FWaaS - default parameter of 'protocol' is wrong
Fix is already merged ** Changed in: neutron Assignee: Reedip (reedip-banerjee) => (unassigned) ** 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/1657182 Title: FWaaS - default parameter of 'protocol' is wrong Status in neutron: Fix Released Bug description: When creating firewall_rule with no '--protocol' option, 'ICMP' is selected. This is actually 'tcp'. In other words, when I specified None as 'protocol', got an error message as if I were specified 'ICMP' as a protocol. [How to reproduce] source devstack/openrc admin admin openstack firewall group rule create --source-port 100:100 Source, destination port are not allowed when protocol is set to ICMP. Neutron server returns request_ids: ['req-35f28579-aa5d-4744-86d8-cbb2a451cd49'] To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1657182/+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 1844607] Re: log error when create neutron port with wrong subnet
** Changed in: neutron
Status: Fix Released => 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/1844607
Title:
log error when create neutron port with wrong subnet
Status in neutron:
In Progress
Bug description:
With Neutron Newton version
There are two networks named share_net and test1 in my env, each with
one subnet. When I create port in share_net, but specify subnet_id of
the test1's subnet, not the subnet of share_net. Create port failed,
but log is "Failed to create port on network
8fd6c0d1-e499-4e29-9786-dadb377f9939, because fixed_ips included
invalid subnet d213e64e-045e-4941-a4bd-ffc049ad792c."
Here we can see network 8fd6c0d1-e499-4e29-9786-dadb377f9939 is test1,
subnet d213e64e-045e-4941-a4bd-ffc049ad792c is the subnet of test1.
The log is confused, actually it should log network
311a12a8-6824-4348-b5b5-80068a0c3785 with invalid subnet d213e64e-
045e-4941-a4bd-ffc049ad792c.
()[root@busybox-openstack-85c44df77f-xk2rx /]# neutron net-list
+--++---+
| id | name
| subnets |
+--++---+
| 311a12a8-6824-4348-b5b5-80068a0c3785 | share_net
| ef7e9220-d478-48f7-819e-80143621f233 192.168.20.0/24 |
| 8fd6c0d1-e499-4e29-9786-dadb377f9939 | test1
| d213e64e-045e-4941-a4bd-ffc049ad792c 192.168.20.0/24 |
+--++---+
()[root@busybox-openstack-85c44df77f-xk2rx /]# neutron port-create
--name nic1 --fixed-ip subnet_id=d213e64e-045e-4941-a4bd-ffc049ad792c
311a12a8-6824-4348-b5b5-80068a0c3785
Invalid input for operation: Failed to create port on network
8fd6c0d1-e499-4e29-9786-dadb377f9939, because fixed_ips included invalid subnet
d213e64e-045e-4941-a4bd-ffc049ad792c.
Neutron server returns request_ids:
['req-e32df57b-0756-4b88-b042-a0b67ccd7fe7']
after inspect code, I found the function code is:
def _get_subnet_for_fixed_ip(self, context, fixed, subnets):
# Subnets are all the subnets belonging to the same network.
if not subnets:
msg = _('IP allocation requires subnets for network')
raise exc.InvalidInput(error_message=msg)
if 'subnet_id' in fixed:
def get_matching_subnet():
for subnet in subnets:
if subnet['id'] == fixed['subnet_id']:
return subnet
subnet = get_matching_subnet()
if not subnet:
subnet = self._get_subnet(context, fixed['subnet_id'])
msg = (_("Failed to create port on network %(network_id)s"
", because fixed_ips included invalid subnet "
"%(subnet_id)s") %
{'network_id': subnet['network_id'],
'subnet_id': fixed['subnet_id']})
raise exc.InvalidInput(error_message=msg)
this function, it use “'network_id': subnet['network_id'] ”, actually it
should use the network passed from api.
master branch also have this problem:
https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#382
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1844607/+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 1874664] Re: Boot more than one instances failed with accelerators in its flavor
Given we are after RC1 (which means that we only accept regression bugfixes for RC2 and later versions), I think we should just document the current caveat in https://docs.openstack.org/api-guide/compute /accelerator-support.html and trying to backport the bugfix for a later Ussuri release (say 21.0.1). ** Also affects: nova/ussuri Importance: Undecided Status: New ** Changed in: nova/ussuri 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/1874664 Title: Boot more than one instances failed with accelerators in its flavor Status in OpenStack Compute (nova): Confirmed Status in OpenStack Compute (nova) ussuri series: New Bug description: When boot more than one instance with accelerator, and the accelerators are in one compute node, there will be two problems as below: One problem is as we always get the first item(alloc_reqs[0]) in alloc_reqs, when we iterator the second instance, it will throw conflict exception when putting the allocations. Another is as we always get the first item in alloc_reqs_by_rp_uuid.get(selected_host.uuid), the selected_alloc_req is always stable, that will cause the values in selections_to_return are same . In fact, it's not right for subsequent operations. More details you can see: https://etherpad.opendev.org/p/filter_scheduler_issue_with_accelerators To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1874664/+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
