[Yahoo-eng-team] [Bug 1789429] [NEW] Glance v2 API doesn't support credentials for image importing
Public bug reported: Old glance v1 API supported credentials specification in the "--copy- from" parameter. However new v2 API doesn't support credentials as well as "swift+https" method. Besides when URL is specified with credentials, these credentials are available via "glance task-show %taskid%" output. ** Affects: glance Importance: Undecided Status: New ** Tags: 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/1789429 Title: Glance v2 API doesn't support credentials for image importing Status in Glance: New Bug description: Old glance v1 API supported credentials specification in the "--copy- from" parameter. However new v2 API doesn't support credentials as well as "swift+https" method. Besides when URL is specified with credentials, these credentials are available via "glance task-show %taskid%" output. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1789429/+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 1812118] [NEW] Neutron doesn't allow to update router external subnets
Public bug reported:
Create a router with an external subnet, then try to update it:
openstack router set --external-gateway 30e25ece-439b-4d9f-a3f7-816d0167d2cd
--fixed-ip subnet=72808793-445e-4fe5-b653-097d720304e8 test
NotFoundException: 404: Client Error for url:
https:///v2.0/routers/9f3edd38-f18b-482b-9060-20773423cb76,
{"NeutronError": {"message": "Port 31c7ad44-41e6-4c2a-87fc-ea749a725690 could
not be found.", "type": "PortNotFound", "detail": ""}}
I expect that this is an issue:
https://github.com/openstack/neutron/blob/b09b8868e93aea437055c041148ccbd095c5c249/neutron/db/l3_db.py#L508
and the context should be: context.elevated(), but I'm not sure whether
it is a security issue.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: external neutron router subnet
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1812118
Title:
Neutron doesn't allow to update router external subnets
Status in neutron:
New
Bug description:
Create a router with an external subnet, then try to update it:
openstack router set --external-gateway 30e25ece-439b-4d9f-a3f7-816d0167d2cd
--fixed-ip subnet=72808793-445e-4fe5-b653-097d720304e8 test
NotFoundException: 404: Client Error for url:
https:///v2.0/routers/9f3edd38-f18b-482b-9060-20773423cb76,
{"NeutronError": {"message": "Port 31c7ad44-41e6-4c2a-87fc-ea749a725690 could
not be found.", "type": "PortNotFound", "detail": ""}}
I expect that this is an issue:
https://github.com/openstack/neutron/blob/b09b8868e93aea437055c041148ccbd095c5c249/neutron/db/l3_db.py#L508
and the context should be: context.elevated(), but I'm not sure
whether it is a security issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1812118/+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 1818318] Re: Network filtering by dns_domain is not supported in the "dns-integration" extension
** 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/1818318 Title: Network filtering by dns_domain is not supported in the "dns- integration" extension Status in neutron: New Bug description: Filtering network by "dns_domain" (http://neutron/v2.0/networks?dns_domain=foo) returns: in_() not yet supported for relationships. For a simple many-to-one, use in_() against the set of foreign key values. However ports filtering by dns_name works fine: http://neutron/v2.0/ports?dns_name=bar I haven't managed to clarify why. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1818318/+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 1818318] [NEW] Network filtering by dns_domain is not supported in the "dns-integration" extension
Public bug reported: Filtering network by "dns_domain" (http://neutron/v2.0/networks?dns_domain=foo) returns: in_() not yet supported for relationships. For a simple many-to-one, use in_() against the set of foreign key values. However ports filtering by dns_name works fine: http://neutron/v2.0/ports?dns_name=bar I haven't managed to clarify why. ** Affects: neutron Importance: Undecided Status: New ** Tags: dns extension neutron ports -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1818318 Title: Network filtering by dns_domain is not supported in the "dns- integration" extension Status in neutron: New Bug description: Filtering network by "dns_domain" (http://neutron/v2.0/networks?dns_domain=foo) returns: in_() not yet supported for relationships. For a simple many-to-one, use in_() against the set of foreign key values. However ports filtering by dns_name works fine: http://neutron/v2.0/ports?dns_name=bar I haven't managed to clarify why. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1818318/+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 1818317] [NEW] Network filtering by MTU is not supported with the "net-mtu-writable" module
Public bug reported:
Read-only (https://github.com/openstack/neutron-
lib/blob/fc2a81058bfd3ba9fd3501660156c71ff1c8129c/neutron_lib/api/definitions/network_mtu.py#L51..L52)
MTU supports listing, however writable "net-mtu-writable"
(https://github.com/openstack/neutron-
lib/blob/fc2a81058bfd3ba9fd3501660156c71ff1c8129c/neutron_lib/api/definitions/network_mtu_writable.py#L54..L56)
doesn't support filtering by MTU:
Bad request with: [GET
http://192.168.200.182:9696/v2.0/networks?mtu=1450=TESTACC-ZtUqAVkR]:
{"NeutronError": {"message": "[u'mtu'] is invalid attribute for filtering",
"type": "HTTPBadRequest", "detail": ""}}
** Affects: neutron
Importance: Undecided
Status: New
** Tags: mtu network neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1818317
Title:
Network filtering by MTU is not supported with the "net-mtu-writable"
module
Status in neutron:
New
Bug description:
Read-only (https://github.com/openstack/neutron-
lib/blob/fc2a81058bfd3ba9fd3501660156c71ff1c8129c/neutron_lib/api/definitions/network_mtu.py#L51..L52)
MTU supports listing, however writable "net-mtu-writable"
(https://github.com/openstack/neutron-
lib/blob/fc2a81058bfd3ba9fd3501660156c71ff1c8129c/neutron_lib/api/definitions/network_mtu_writable.py#L54..L56)
doesn't support filtering by MTU:
Bad request with: [GET
http://192.168.200.182:9696/v2.0/networks?mtu=1450=TESTACC-ZtUqAVkR]:
{"NeutronError": {"message": "[u'mtu'] is invalid attribute for filtering",
"type": "HTTPBadRequest", "detail": ""}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1818317/+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 1818318] Re: Network filtering by dns_domain is not supported in the "dns-integration" extension
fixed in a newer neutron ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1818318 Title: Network filtering by dns_domain is not supported in the "dns- integration" extension Status in neutron: Invalid Bug description: Filtering network by "dns_domain" (http://neutron/v2.0/networks?dns_domain=foo) returns: in_() not yet supported for relationships. For a simple many-to-one, use in_() against the set of foreign key values. However ports filtering by dns_name works fine: http://neutron/v2.0/ports?dns_name=bar I haven't managed to clarify why. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1818318/+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 1872753] [NEW] Updating EC2 credential blob can lead to a ec2 credential id / credential id mismatch
Public bug reported: Updating ec2 credential blob field via "openstack credential update" allows to update the EC2 credential access ID. Considering that EC2 credential access ID is used to calculate an ID of the "credential" (https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/users.py#L363, https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/common/utils.py#L101), the update action doesn't update the actual credential ID using a new access ID sha256sum. It can lead to orphaned ec2 credentials in the database. ** 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/1872753 Title: Updating EC2 credential blob can lead to a ec2 credential id / credential id mismatch Status in OpenStack Identity (keystone): New Bug description: Updating ec2 credential blob field via "openstack credential update" allows to update the EC2 credential access ID. Considering that EC2 credential access ID is used to calculate an ID of the "credential" (https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/users.py#L363, https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/common/utils.py#L101), the update action doesn't update the actual credential ID using a new access ID sha256sum. It can lead to orphaned ec2 credentials in the database. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1872753/+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 1971691] [NEW] Support application credentials as a source for EC2 auth
Public bug reported:
Unfortunately EC2 credentials are not secure enough. EC2 credentials are
not protected by limited roles, expiration time, access rules and ec2
secret part is visible via get/list API calls. Leaked EC2 credentials
imply a big security risk in terms of access, because EC2 creds token
has the same power as a regular user/pass auth.
EC2 AUTH is actively used by Swift S3 emulation (not limited only to
Swift, btw.) it would be nice to use application credentials as an auth
source in keystone internals and issue a limited access token. With all
features application credentials provide, EC2 can get a second wind.
An example of EC2 auth request with application credentials:
$ openstack application credential list
+--+---+--+-++
| ID | Name | Project ID
| Description | Expires At |
+--+---+--+-++
| 3defd466f04646d094a1ee4b6afc53e8 | test |
f8d450e9cb7b4f1cbf664401d5bf1d29 | None| 2219-02-13T12:12:12.00 |
+--+---+--+-++
POST http://keystone:8080/v3/ec2tokens
{
"credentials": {
"access": "3defd466f04646d094a1ee4b6afc53e8",
"body_hash": "***",
"headers": {
"Accept-Encoding": "identity",
"Authorization": "AWS4-HMAC-SHA256
Credential=3defd466f04646d094a1ee4b6afc53e8/20220505/RegionOne/s3/aws4_request,
SignedHeaders=host;x-amz-content-sha256;x-amz-date,
Signature=appCredSecretBasedSignature",
"Host": "keystone:8080",
"User-Agent": "aws-cli/1.18.69 Python/3.8.10 Linux/5.4.0-109-generic
botocore/1.16.19",
"X-Amz-Content-Sha256":
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"X-Amz-Date": "20220505T101354Z",
"X-Amz-SignedHeaders": "host;x-amz-content-sha256;x-amz-date"
},
"host": "",
"params": {},
"path": "/",
"signature": "appCredSecretBasedSignature",
"verb": "GET"
}
}
An example of EC2 auth token response with application credentials:
{
"token": {
"application_credential": {
"access_rules": [
{
"id": "9416a34e7f3b45ecb029063d8a239463",
"method": "GET",
"path": "/v1/secrets/e8f07eae-3a6b-4c3c-a847-f14f6e348d8f**",
"service": "key-manager"
}
],
"id": "3defd466f04646d094a1ee4b6afc53e8",
"name": "test",
"restricted": true
},
"audit_ids": [
"m6C3NgSiQmqQnrBRySYW2A"
],
"catalog": [...],
"expires_at": "2022-05-05T18:24:48.00Z",
"is_admin_project": false,
"is_domain": false,
"issued_at": "2022-05-05T10:24:48.00Z",
"methods": [
"application_credential"
],
"project": {
"domain": {
"id": "default",
"name": "Default"
},
"id": "f8d450e9cb7b4f1cbf664401d5bf1d29",
"name": "test"
},
"roles": [
{
"id": "a66c3a324bc24c0da7259faa03f2704d",
"name": "limited_role"
}
],
"user": {
"domain": {
"id": "default",
"name": "Default"
},
"id": "0c4cac95c039441d9b8bb509fe836110",
"name": "appCredOwner",
"password_expires_at": "2022-09-07T18:13:38.126030"
}
}
}
** Affects: keystone
Importance: Undecided
Status: New
** Tags: application credentials ec2
** Description changed:
Unfortunately EC2 credentials are not secure enough. EC2 credentials are
not protected by limited roles, expiration time, access rules and ec2
secret part is visible via get/list API calls. Leaked EC2 credentials
imply a big security risk in terms of access, because EC2 creds token
has the same power as a regular user/pass auth.
Hence EC2 AUTH is actively used by Swift S3 emulation (not limited only
to Swift, btw.) it would be nice to use application credentials as an
auth source in keystone internals and issue a limited access token. With
all features application credentials provide, EC2 can get a second wind.
An example of EC2 auth request with application credentials:
$ openstack application credential list
+--+---+--+-++
| ID | Name | Project ID
| Description | Expires At |
+--+---+--+-++
| 3defd466f04646d094a1ee4b6afc53e8 | test |
f8d450e9cb7b4f1cbf664401d5bf1d29 | None| 2219-02-13T12:12:12.00 |
[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 2046457] [NEW] ovn provider fails with "AttributeError: 'Client' object has no attribute 'ports'"
Public bug reported: octavia-driver-agent[91903]: ERROR futurist.periodics [-] Failed to call periodic 'ovn_octavia_provider.maintenance.DBInconsistenciesPeriodics.change_device_owner_lb_hm_ports' (it runs every 600.00 seconds): AttributeError: 'Client' object has no attribute 'ports' octavia-driver-agent[91903]: ERROR futurist.periodics Traceback (most recent call last): octavia-driver-agent[91903]: ERROR futurist.periodics File "/usr/local/lib/python3.10/dist-packages/futurist/periodics.py", line 290, in run octavia-driver-agent[91903]: ERROR futurist.periodics work() octavia-driver-agent[91903]: ERROR futurist.periodics File "/usr/local/lib/python3.10/dist-packages/futurist/periodics.py", line 64, in __call__ octavia-driver-agent[91903]: ERROR futurist.periodics return self.callback(*self.args, **self.kwargs) octavia-driver-agent[91903]: ERROR futurist.periodics File "/usr/local/lib/python3.10/dist-packages/futurist/periodics.py", line 178, in decorator octavia-driver-agent[91903]: ERROR futurist.periodics return f(*args, **kwargs) octavia-driver-agent[91903]: ERROR futurist.periodics File "/opt/stack/ovn-octavia-provider/ovn_octavia_provider/maintenance.py", line 79, in change_device_owner_lb_hm_ports octavia-driver-agent[91903]: ERROR futurist.periodics ovn_lb_hm_ports = neutron_client.ports( octavia-driver-agent[91903]: ERROR futurist.periodics AttributeError: 'Client' object has no attribute 'ports' see also k8s e2e test results: https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/cloud- provider-openstack/2504/openstack-cloud-controller- manager-e2e-test/1735270733262622720 ** Affects: neutron Importance: Undecided Status: New ** Tags: ovn-octavia-provider -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2046457 Title: ovn provider fails with "AttributeError: 'Client' object has no attribute 'ports'" Status in neutron: New Bug description: octavia-driver-agent[91903]: ERROR futurist.periodics [-] Failed to call periodic 'ovn_octavia_provider.maintenance.DBInconsistenciesPeriodics.change_device_owner_lb_hm_ports' (it runs every 600.00 seconds): AttributeError: 'Client' object has no attribute 'ports' octavia-driver-agent[91903]: ERROR futurist.periodics Traceback (most recent call last): octavia-driver-agent[91903]: ERROR futurist.periodics File "/usr/local/lib/python3.10/dist-packages/futurist/periodics.py", line 290, in run octavia-driver-agent[91903]: ERROR futurist.periodics work() octavia-driver-agent[91903]: ERROR futurist.periodics File "/usr/local/lib/python3.10/dist-packages/futurist/periodics.py", line 64, in __call__ octavia-driver-agent[91903]: ERROR futurist.periodics return self.callback(*self.args, **self.kwargs) octavia-driver-agent[91903]: ERROR futurist.periodics File "/usr/local/lib/python3.10/dist-packages/futurist/periodics.py", line 178, in decorator octavia-driver-agent[91903]: ERROR futurist.periodics return f(*args, **kwargs) octavia-driver-agent[91903]: ERROR futurist.periodics File "/opt/stack/ovn-octavia-provider/ovn_octavia_provider/maintenance.py", line 79, in change_device_owner_lb_hm_ports octavia-driver-agent[91903]: ERROR futurist.periodics ovn_lb_hm_ports = neutron_client.ports( octavia-driver-agent[91903]: ERROR futurist.periodics AttributeError: 'Client' object has no attribute 'ports' see also k8s e2e test results: https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/cloud- provider-openstack/2504/openstack-cloud-controller- manager-e2e-test/1735270733262622720 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2046457/+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
