[Yahoo-eng-team] [Bug 2006631] Re: service token does not work if user auth is token based
This looks like a keystone middleware issue to me ... you should check with the Keystone team about how this feature is supposed to work and whether it's a bug or a configuration problem. ** Also affects: keystone Importance: Undecided Status: New -- 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/2006631 Title: service token does not work if user auth is token based Status in Cinder: New Status in OpenStack Identity (keystone): New Bug description: To deal with long running operation service token is used alongwith user token. In this case user token is generated from password auth type and then service token wrapped alongwith user token is used for authentication, which allows to run operation upto 48 hours fine. However if user token is used as token auth type and then service token wrapped alongwith user token, operation fails immediately when user token is expired. That service token is of no use in this case, this is bug and needs to fixed. steps to reproduce - https://paste.opendev.org/show/bAoAjwVMVCBxsNt6Z9kB/ Failure logs - https://paste.opendev.org/show/bhAZ33JYpkhrbBLZzCdK/ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/2006631/+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 2006784] [NEW] dhcp lookups depend on end-of-life dhclient
Public bug reported: When using DataSourceHetzner, there is a required dhcp lookup. This digs down to a function named `maybe_perform_dhcp_discovery` which breaks when a `which dhclient` does not return a binary. This raises a `NoDHCPLeaseMissingDhclientError`. I have only tested this under NixOS, as its one of the first distributions to have have removed `dhclient` from its the package tree following the deprecation by ISC's to the package. DHCP lookups should be changed to support a non-deprecated dhcp library. Cloud-provider: Hetzner Cloud-init config: ``` system_info: distro: nixos network: renderers: [networkd] users: - root disable_root: false preserve_hostname: false cloud_init_modules: - set_hostname - update_hostname - update_etc_hosts cloud_config_modules: [] cloud_final_modules: [] datasource_list: - DataSourceHetzner ``` Source where error is raised from: https://github.com/canonical/cloud-init/blob/b3978cbd6c68c883f5ab02630d8d7fcb220b270c/cloudinit/net/dhcp.py#L69 End-of-life notice from ISC at 02 Jul 2021: https://www.isc.org/blogs/dhcp-client-relay-eom/ ** 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/2006784 Title: dhcp lookups depend on end-of-life dhclient Status in cloud-init: New Bug description: When using DataSourceHetzner, there is a required dhcp lookup. This digs down to a function named `maybe_perform_dhcp_discovery` which breaks when a `which dhclient` does not return a binary. This raises a `NoDHCPLeaseMissingDhclientError`. I have only tested this under NixOS, as its one of the first distributions to have have removed `dhclient` from its the package tree following the deprecation by ISC's to the package. DHCP lookups should be changed to support a non-deprecated dhcp library. Cloud-provider: Hetzner Cloud-init config: ``` system_info: distro: nixos network: renderers: [networkd] users: - root disable_root: false preserve_hostname: false cloud_init_modules: - set_hostname - update_hostname - update_etc_hosts cloud_config_modules: [] cloud_final_modules: [] datasource_list: - DataSourceHetzner ``` Source where error is raised from: https://github.com/canonical/cloud-init/blob/b3978cbd6c68c883f5ab02630d8d7fcb220b270c/cloudinit/net/dhcp.py#L69 End-of-life notice from ISC at 02 Jul 2021: https://www.isc.org/blogs/dhcp-client-relay-eom/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2006784/+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 2006775] [NEW] [feature] support key by url in apt configure module
Public bug reported: A common way of distributing keys is by hosting them at a URL for download. This is not currently supported by the apt configure module, and would be a simple addition. Example usage (note the suggested 'keyurl' key) apt: sources: source1: keyurl: 'https://domain.io/keys/key1.gpg' source: 'deb [signed-by=$KEY_FILE] http:/// jammy main' ** 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/2006775 Title: [feature] support key by url in apt configure module Status in cloud-init: New Bug description: A common way of distributing keys is by hosting them at a URL for download. This is not currently supported by the apt configure module, and would be a simple addition. Example usage (note the suggested 'keyurl' key) apt: sources: source1: keyurl: 'https://domain.io/keys/key1.gpg' source: 'deb [signed-by=$KEY_FILE] http:/// jammy main' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2006775/+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 2006770] [NEW] server list with IP filter doesn't work as expected
Public bug reported:
If a project has two servers with 10.10.10.10 and 10.10.10.109 IPs, the
"curl -s 'https://nova:443/v2.1/servers?ip=10.10.10.10'" request returns
two servers in a response.
This happens because neutron API has an "ip-substring-filtering"
extension turned on:
$ curl -s "https://neutron/v2.0/extensions; -H "X-Auth-Token: ${OS_AUTH_TOKEN}"
| jq -r '.extensions[]|select(.alias=="ip-substring-filtering")'
{
"name": "IP address substring filtering",
"alias": "ip-substring-filtering",
"description": "Provides IP address substring filtering when listing ports",
"updated": "2017-11-28T09:00:00-00:00",
"links": []
}
And there is no possibility to filter IPs with an exact match like it's
done with a
"https://neutron/v2.0/ports?fixed_ips=ip_address%3D10.10.10.10; call.
Another problem is that ip/ip6 fields are marked as regexp in both
SCHEMA and CLI:
https://github.com/openstack/nova/blob/49aa40394a4857a06191b05ea3b15913f328a8d0/nova/api/openstack/compute/schemas/servers.py#L638-L639
(values which are not regexp compatible are rejected on the early stage)
$ openstack server list --help | grep -- --ip
[--ip ]
[--ip6 ] [--name ]
--ip
--ip6
But they are not considered as regexp afterwards. Moreover the
https://github.com/openstack/nova/blob/a2964417822bd1a4a83fa5c27282d2be1e18868a/nova/compute/api.py#L3028-L3039
mapping doesn't work, because "fixed_ip" is never allowed in
"search_opts" map.
Changing "fixed_ip" key to an "ip" key (BTW, there is no "fixed_ip6"
mapping, it also should be considered once someone decide to fix this
issue) breaks substring filtering, because the filter finally becomes
"'ip': '^10\\.10\\.10\\.10$'".
Therefore if there is no "substring filtering" neutron extension, the
regexp filter mappings must consider this (or even be removed).
And the final call: there should be a way for a user to define whether
user wants to use substr, exact match or regexp.
See also: https://stackoverflow.com/questions/64549906/how-openstack-
client-get-server-list-with-accurate-ip-address
** Affects: nova
Importance: Undecided
Status: New
** Tags: filter fixed ip neutron nova
--
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/2006770
Title:
server list with IP filter doesn't work as expected
Status in OpenStack Compute (nova):
New
Bug description:
If a project has two servers with 10.10.10.10 and 10.10.10.109 IPs,
the "curl -s 'https://nova:443/v2.1/servers?ip=10.10.10.10'" request
returns two servers in a response.
This happens because neutron API has an "ip-substring-filtering"
extension turned on:
$ curl -s "https://neutron/v2.0/extensions; -H "X-Auth-Token:
${OS_AUTH_TOKEN}" | jq -r
'.extensions[]|select(.alias=="ip-substring-filtering")'
{
"name": "IP address substring filtering",
"alias": "ip-substring-filtering",
"description": "Provides IP address substring filtering when listing ports",
"updated": "2017-11-28T09:00:00-00:00",
"links": []
}
And there is no possibility to filter IPs with an exact match like
it's done with a
"https://neutron/v2.0/ports?fixed_ips=ip_address%3D10.10.10.10; call.
Another problem is that ip/ip6 fields are marked as regexp in both
SCHEMA and CLI:
https://github.com/openstack/nova/blob/49aa40394a4857a06191b05ea3b15913f328a8d0/nova/api/openstack/compute/schemas/servers.py#L638-L639
(values which are not regexp compatible are rejected on the early
stage)
$ openstack server list --help | grep -- --ip
[--ip ]
[--ip6 ] [--name ]
--ip
--ip6
But they are not considered as regexp afterwards. Moreover the
https://github.com/openstack/nova/blob/a2964417822bd1a4a83fa5c27282d2be1e18868a/nova/compute/api.py#L3028-L3039
mapping doesn't work, because "fixed_ip" is never allowed in
"search_opts" map.
Changing "fixed_ip" key to an "ip" key (BTW, there is no "fixed_ip6"
mapping, it also should be considered once someone decide to fix this
issue) breaks substring filtering, because the filter finally becomes
"'ip': '^10\\.10\\.10\\.10$'".
Therefore if there is no "substring filtering" neutron extension, the
regexp filter mappings must consider this (or even be removed).
And the final call: there should be a way for a user to define whether
user wants to use substr, exact match or regexp.
See also: https://stackoverflow.com/questions/64549906/how-openstack-
client-get-server-list-with-accurate-ip-address
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/2006770/+subscriptions
--
Mailing list:
[Yahoo-eng-team] [Bug 2003095] Re: [RFE] Provide Port Binding Information for Manila Share Server Live Migration
Reviewed: https://review.opendev.org/c/openstack/neutron/+/869295 Committed: https://opendev.org/openstack/neutron/commit/5c697b8d60571ef4a052586a73edd3d513d0d635 Submitter: "Zuul (22348)" Branch:master commit 5c697b8d60571ef4a052586a73edd3d513d0d635 Author: Maurice Escher Date: Wed Oct 19 13:33:36 2022 +0200 allow manila ports to do multiple port binding for ML2 Similar to Nova live migration (see https://review.opendev.org/c/openstack/neutron/+/414251/74/neutron/plugins/ml2/plugin.py#2005) Manila wants to do share live migration, and needs to modify its ports in a similar way: issue port binding upfront to determine the segmentation id in the target network segment. Closes-Bug: #2003095 Change-Id: I647d00a30564ade246e704ff199b6aceafdc4c50 ** 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/2003095 Title: [RFE] Provide Port Binding Information for Manila Share Server Live Migration Status in neutron: Fix Released Bug description: Hi, similar to Nova, where this feature is described by https://review.opendev.org/c/openstack/neutron-specs/+/309416/ and implemented around https://bugs.launchpad.net/neutron/+bug/1580880, there is a Share Server Live Migration feature in Manila (see https://review.opendev.org/c/openstack/manila-specs/+/735970), that would benefit of this port binding extension. If the migration target is in a different network segment, Manila needs to be able to do the port binding before the actual migration starts. This is relevant for the neutron bind driver in manila, that was added to support hierarchical port binding in https://review.opendev.org/c/openstack/manila-specs/+/315985 Best regards, Maurice To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2003095/+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 2006763] [NEW] [neutron-tempest-plugin] "guestmount" command not found in Ubuntu 20.04
Public bug reported: Error: https://1e4c070c6d8fc22f3cfe- bf313b0386a54af757ff2672eb4d7d35.ssl.cf1.rackcdn.com/873147/1/check/neutron- tempest-plugin-scenario-linuxbridge-ussuri/d009a1f/job-output.txt Snippet: https://paste.opendev.org/show/b0WaYhmqzBcD9Io181Ts/ ** Affects: neutron Importance: Undecided Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: New ** Changed in: neutron Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2006763 Title: [neutron-tempest-plugin] "guestmount" command not found in Ubuntu 20.04 Status in neutron: New Bug description: Error: https://1e4c070c6d8fc22f3cfe- bf313b0386a54af757ff2672eb4d7d35.ssl.cf1.rackcdn.com/873147/1/check/neutron- tempest-plugin-scenario-linuxbridge-ussuri/d009a1f/job-output.txt Snippet: https://paste.opendev.org/show/b0WaYhmqzBcD9Io181Ts/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2006763/+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 1871419] Re: need multihash info in glance user, admin guides
Reviewed: https://review.opendev.org/c/openstack/glance/+/755338 Committed: https://opendev.org/openstack/glance/commit/438758db2feeb59d75d6432b84e449df52ba84d6 Submitter: "Zuul (22348)" Branch:master commit 438758db2feeb59d75d6432b84e449df52ba84d6 Author: pragathi93 Date: Wed Sep 30 13:21:03 2020 +0530 Add multihash info in glance documentation New docs added for os_hash_algo in user guide and admin guide. Change-Id: Id78be3935998b9c5acdd0706393117e892e5ab59 Closes-bug:#1871419 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1871419 Title: need multihash info in glance user, admin guides Status in Glance: Fix Released Bug description: The user guide and admin guide need info about the secure "multihash" feature. Both need to describe the idea of the self-describing secure hash. Additionally: admin guide: the os_hash_algo is operator-configurable; explain how user guide: the os_hash_algo value can be passed to hashlib to obtain a digest algorithm to validate a download Current sources for this info are: (1) description of os_hash_value, os_hash_algo in the api-ref (2) the multihash spec: https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/glance/multihash.html (3) rocky release notes: https://docs.openstack.org/releasenotes/glance/rocky.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1871419/+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 1939690] Re: The api-ref response and the actual response returned from the Create Tags API does not match
Reviewed: https://review.opendev.org/c/openstack/glance/+/856098
Committed:
https://opendev.org/openstack/glance/commit/2872130bb932b980902e6115fff60f6b7754e3db
Submitter: "Zuul (22348)"
Branch:master
commit 2872130bb932b980902e6115fff60f6b7754e3db
Author: Mridula Joshi
Date: Tue Sep 6 12:17:23 2022 +
Fixes the api-ref response
The response returned from the Create Tags API
'/v2/metadefs/namespaces/{namespace_name}/tags' does not match
the response in api-ref.
This patch corrects the api-ref response.
Closes-Bug: #1939690
Change-Id: Icdafa6f55b434977d83148a0b0a958f35e99afac
** Changed in: glance
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1939690
Title:
The api-ref response and the actual response returned from the Create
Tags API does not match
Status in Glance:
Fix Released
Bug description:
The response returned from the Create Tags API
'/v2/metadefs/namespaces/{namespace_name}/tags' does not match the
response in api-ref.
The response mentioned in the api-ref:
https://docs.openstack.org/api-ref/image/v2/metadefs-index.html?expanded=create-tags-detail#id88
{
"created_at": "2015-05-09T01:12:31Z",
"name": "added-sample-tag",
"updated_at": "2015-05-09T01:12:31Z"
}
The actual response returned from API :
RESP BODY: {"tags": [{"name": "sample-tag1"}, {"name": "sample-tag2"},
{"name": "sample-tag3"}]}
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1939690/+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 2004656] Re: "rpc_workers" config variable needs to be registered in stadium projects
Reviewed: https://review.opendev.org/c/openstack/neutron/+/872644 Committed: https://opendev.org/openstack/neutron/commit/47fef55e25fb1b7d3c6c7d6083a916e26fd45b6d Submitter: "Zuul (22348)" Branch:master commit 47fef55e25fb1b7d3c6c7d6083a916e26fd45b6d Author: Rodolfo Alonso Hernandez Date: Fri Feb 3 13:11:24 2023 +0100 Add a method to retrieve and register "rpc_workers" config knob This new method retrieves the config option "rpc_workers" from the configuration. If this option is not loaded, the method registers the ``neutron.conf.service.SERVICE_OPTS`` options before reading the knob again. Closes-Bug: #2004656 Related-Bug: #1889737 Change-Id: I1f99cb32f33cc91141136cb4e3fbd33715530c59 ** 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/2004656 Title: "rpc_workers" config variable needs to be registered in stadium projects Status in neutron: Fix Released Bug description: Other projects than Neutron are reporting the following error [1]: oslo_config.cfg.NoSuchOptError: no such option rpc_workers in group [DEFAULT] Snippet: https://paste.opendev.org/show/bCjZsBIMlMg2sxEWIxak/ This config error seems to be related to https://review.opendev.org/c/openstack/neutron/+/823637. [1]https://4e430b001e9b96de0fdd- ba0257f15ec13d0dd0c3147f2089533f.ssl.cf2.rackcdn.com/862102/5/check/openstack- tox-py38/478a6c8/testr_results.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2004656/+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 2006735] [NEW] [OVN] OVN trunk driver is not setting the OVN LSP "external_ids:neutron:device_owner" value
Public bug reported: The methods ``OVNTrunkHandler._set_binding_profile`` and ``OVNTrunkHandler._unset_binding_profile`` are not updating the OVN LSP device owner value (stored in "external_ids") when setting or removing the binding profile. ** Affects: neutron Importance: Undecided Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: New ** Changed in: neutron Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2006735 Title: [OVN] OVN trunk driver is not setting the OVN LSP "external_ids:neutron:device_owner" value Status in neutron: New Bug description: The methods ``OVNTrunkHandler._set_binding_profile`` and ``OVNTrunkHandler._unset_binding_profile`` are not updating the OVN LSP device owner value (stored in "external_ids") when setting or removing the binding profile. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2006735/+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 2006734] [NEW] [OVN] OVN trunk driver is not bumping the OVN LSP "external_ids:revision_number"
Public bug reported: The OVN trunk driver is not bumping the OVN LSP "external_ids:revision_number" after updating the Neutron DB register. The methods ``OVNTrunkHandler._set_binding_profile`` and ``OVNTrunkHandler._unset_binding_profile`` are called from ``_set_sub_ports`` and ``_unset_sub_ports`` respectively. These methods create a Neutron DB and a OVN DB transactions in the same with clause. Inside both transactions, the port register (Neutron DB and OVN DB) is modified. However, the OVN register revision_number is not bumped consequently. That forces the maintenance task to review the OVN register and force an update. ** Affects: neutron Importance: Undecided Status: 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/2006734 Title: [OVN] OVN trunk driver is not bumping the OVN LSP "external_ids:revision_number" Status in neutron: New Bug description: The OVN trunk driver is not bumping the OVN LSP "external_ids:revision_number" after updating the Neutron DB register. The methods ``OVNTrunkHandler._set_binding_profile`` and ``OVNTrunkHandler._unset_binding_profile`` are called from ``_set_sub_ports`` and ``_unset_sub_ports`` respectively. These methods create a Neutron DB and a OVN DB transactions in the same with clause. Inside both transactions, the port register (Neutron DB and OVN DB) is modified. However, the OVN register revision_number is not bumped consequently. That forces the maintenance task to review the OVN register and force an update. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2006734/+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
