from:"Lana"

[Yahoo-eng-team] [Bug 1861493] [NEW] Nova sends an "X-Service-Token" header when "send_service_user_token" is disabled

2020-01-31 Thread Lana Kaleif

Public bug reported:

Description
===
In the interaction between nova-api and cinder, it is possible to enable the 
required check of service_user tokens.
When I try to explicitly turn off the sending of the user’s service token and 
enable the mandatory check of its availability on the receiving side, I do not 
get the expected error because the X-Service-Token header is still sent by 
nova-api.

Steps to reproduce
==
cinder includes required token checking:

[keystone_authtoken]
...
service_token_roles = admin
service_token_roles_required = true


in nova, token sending is explicitly disabled and the user service is not set:

[service_user]
send_service_user_token = false

verification is performed on the example of the operation of volume attach:
openstack server add volume 0801102f-f9ba-42c5-b32a-85b4a7465122 
a7fd514c-c871-4f69-a89f-bd44864a5814 --device /dev/vdb

Expected result
===
with this configuration, error 401 is expected

Actual result
=
no errors occur and the attach operation is successful.
multiple checks were made including the option to completely restart the servers

Environment
===
CentOS 7
release: train
nova: 15.1.0
cinder: 5.0.0

Logs & Configs
==
we intercept requests that go to the cinder port (8776) and we see that 
192.168.50.81.49226 (which is the nova-api process) sends requests with the 
X-Service-Token header (which we previously disabled in nova.conf). Full log 
(req/res) of adding volume in attachment.

[root@centos ~]# tcpdump -i enp2s0f0 -n -S -s 1024 -A 'tcp dst port
8776'

06:20:21.870330 IP 192.168.50.81.49226 > 192.168.50.80.8776: Flags [P.], seq 
1696694971:1696695677, ack 922604522, win 58, options [nop,nop,TS val 3747722 
ecr 3644290], length 706
E5@.@.2Q..2P.J"He!..6..:...
.9/..7..GET 
/v3/27c47772a3f442e4a81decb6b68e8376/volumes/a7fd514c-c871-4f69-a89f-bd44864a5814
 HTTP/1.1
Host: 192.168.50.80:8776
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: application/json
User-Agent: python-cinderclient
X-Service-Token: 
gABeMrv1SxDwllx8lrDYiP6o0kMlr1hJu34q2N7WgTcsQ15GXU7s2EDG91DX0XOUz0YTS9Q-_nxuRJ5lbZfWDBgk2spJr9csJ1VhNWQhrZUZWhkBk3KMU6GwgC0X3kO5o4dIw41rj1VmH4TfIdV9bSEWjA3qMLjVYKdryyUzhCN1gZQISl0
X-Auth-Token: 
gABeMrv0vSJ6P8pLF7BDLimZ_LxhvKYCvEzWk_TZ62hIaDNnlFHRMx1rrIvDNl6Z78mv6C-EYWRqvURHCP6x9FCuhd16-i25gO4AUVi2Qo2-N-wpxO6dnbOHuuI6G8gtYu3ZPMuaHkn3uk-aaf7zh3PZ__OQy4mtZir6Qt7b5xqPb4QJcGg
X-OpenStack-Request-ID: req-a4ad6f8b-3f49-44d0-99b4-b7fa026017c6


06:20:22.184182 IP 192.168.50.81.49226 > 192.168.50.80.8776: Flags [.], ack 
922606483, win 65, options [nop,nop,TS val 3748036 ecr 3644604], length 0
E..4.6@.@.2Q..2P.J"He!.}6..A...
.90..7..
06:20:22.547486 IP 192.168.50.81.49226 > 192.168.50.80.8776: Flags [P.], seq 
1696695677:1696696271, ack 922606483, win 65, options [nop,nop,TS val 3748399 
ecr 3644604], length 594
E7@.@..H..2Q..2P.J"He!.}6..AG..
.92/.7..GET / HTTP/1.1
Host: 192.168.50.80:8776
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: nova-api keystoneauth1/3.17.1 python-requests/2.21.0 CPython/2.7.5
X-Service-Token: 
gABeMrv1SxDwllx8lrDYiP6o0kMlr1hJu34q2N7WgTcsQ15GXU7s2EDG91DX0XOUz0YTS9Q-_nxuRJ5lbZfWDBgk2spJr9csJ1VhNWQhrZUZWhkBk3KMU6GwgC0X3kO5o4dIw41rj1VmH4TfIdV9bSEWjA3qMLjVYKdryyUzhCN1gZQISl0
X-Auth-Token: 
gABeMrv0vSJ6P8pLF7BDLimZ_LxhvKYCvEzWk_TZ62hIaDNnlFHRMx1rrIvDNl6Z78mv6C-EYWRqvURHCP6x9FCuhd16-i25gO4AUVi2Qo2-N-wpxO6dnbOHuuI6G8gtYu3ZPMuaHkn3uk-aaf7zh3PZ__OQy4mtZir6Qt7b5xqPb4QJcGg


06:20:22.553939 IP 192.168.50.81.49226 > 192.168.50.80.8776: Flags [.], ack 
922607474, win 71, options [nop,nop,TS val 3748405 ecr 3644974], length 0
E..4.8@.@.2Q..2P.J"He!..6..r...G...
.925.7..
06:20:22.564940 IP 192.168.50.81.49226 > 192.168.50.80.8776: Flags [P.], seq 
1696696271:1696697181, ack 922607474, win 71, options [nop,nop,TS val 3748416 
ecr 3644974], length 910
E9@.@..
..2Q..2P.J"He!..6..r...G...
.9...@.7..post /v3/27c47772a3f442e4a81decb6b68e8376/attachments HTTP/1.1
Host: 192.168.50.80:8776
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: application/json
User-Agent: python-cinderclient
X-Service-Token: 
gABeMrv1SxDwllx8lrDYiP6o0kMlr1hJu34q2N7WgTcsQ15GXU7s2EDG91DX0XOUz0YTS9Q-_nxuRJ5lbZfWDBgk2spJr9csJ1VhNWQhrZUZWhkBk3KMU6GwgC0X3kO5o4dIw41rj1VmH4TfIdV9bSEWjA3qMLjVYKdryyUzhCN1gZQISl0
X-Auth-Token: 
gABeMrv0vSJ6P8pLF7BDLimZ_LxhvKYCvEzWk_TZ62hIaDNnlFHRMx1rrIvDNl6Z78mv6C-EYWRqvURHCP6x9FCuhd16-i25gO4AUVi2Qo2-N-wpxO6dnbOHuuI6G8gtYu3ZPMuaHkn3uk-aaf7zh3PZ__OQy4mtZir6Qt7b5xqPb4QJcGg
OpenStack-API-Version: volume 3.44
Content-Type: application/json
X-OpenStack-Request-ID: req-a4ad6f8b-3f49-44d0-99b4-b7fa026017c6
Content-Length: 147

** Affects: nova
 Importance: Undecided
 Status: New

** Attachment added: "with_disabled_service_user.log"
   
https://bugs.launchpad.net/bugs/1861493/+attachment/5324405/+files/with_disabled_service_user.log

-- 
You received

[Yahoo-eng-team] [Bug 1526818] Re: Install guide: Add arp_ignore (sysctl.conf) to the other IP options

2017-02-28 Thread Lana

** Changed in: openstack-manuals
   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/1526818

Title:
  Install guide: Add arp_ignore (sysctl.conf) to the other IP options

Status in neutron:
  New
Status in OpenStack Compute (nova):
  Invalid
Status in openstack-manuals:
  Fix Released

Bug description:
  We are facing a very strange behaviour of ARP in tenant networks,
  causing Windows guests to incorrectly decline DHCP addresses. These
  VMs apparently do an ARP request for the address they have been
  offered, discarding them in case a different MAC is reporting to own
  that IP already.

  We are using openvswitch-agent with ml2 plugin.

  Investigating this issue using Linux guests. Please look at the
  following example. A VM with the fixed-ip 192.168.1.15 reports the
  following ARP cache:

 root@michael-test2:~# arp
 Address  HWtype  HWaddress   Flags Mask
Iface
 host-192-168-1-2.openst  ether   fa:16:3e:de:ab:ea   C 
eth0
 192.168.1.13 ether   a6:b2:dc:d8:39:c1   C 
eth0
 192.168.1.119(incomplete)  
eth0
 host-192-168-1-20.opens  ether   fa:16:3e:76:43:ce   C 
eth0
 host-192-168-1-19.opens  ether   fa:16:3e:0d:a6:0b   C 
eth0
 host-192-168-1-1.openst  ether   fa:16:3e:2a:81:ff   C 
eth0
 192.168.1.14 ether   0e:bf:04:b7:ed:52   C 
eth0
 
  Both 192.168.1.13 and 192.168.1.14 do not exist in this subnet, and their MAC 
addresses a6:b2:dc:d8:39:c1 and 0e:bf:04:b7:ed:52 actually belong to other 
instance qbr* and qvb* devices, living on their respective hypervisor hosts!

  Looking at 0e:bf:04:b7:ed:52, for example, yields

 # ip link list | grep -C1 -e 0e:bf:04:b7:ed:52
 59: qbr9ac24ac1-e1:  mtu 1500 qdisc 
noqueue state UP mode DEFAULT group default 
 link/ether 0e:bf:04:b7:ed:52 brd ff:ff:ff:ff:ff:ff
 60: qvo9ac24ac1-e1:  mtu 1500 
qdisc pfifo_fast master ovs-system state UP mode DEFAULT group default qlen 1000
 --
 61: qvb9ac24ac1-e1:  mtu 1500 
qdisc pfifo_fast master qbr9ac24ac1-e1 state UP mode DEFAULT group default qlen 
1000
 link/ether 0e:bf:04:b7:ed:52 brd ff:ff:ff:ff:ff:ff
 62: tap9ac24ac1-e1:  mtu 1500 qdisc 
pfifo_fast master qbr9ac24ac1-e1 state UNKNOWN mode DEFAULT group default qlen 
500

  on the compute node. Using tcpdump on qbr9ac24ac1-e1 on the host and
  triggering a fresh ARM lookup from the guest results in

 # tcpdump -i qbr9ac24ac1-e1 -vv -l | grep ARP
 tcpdump: WARNING: qbr9ac24ac1-e1: no IPv4 address assigned
 tcpdump: listening on qbr9ac24ac1-e1, link-type EN10MB (Ethernet), capture 
size 65535 bytes
 14:00:32.089726 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.1.14 tell 192.168.1.15, length 28
 14:00:32.089740 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.14 
is-at 0e:bf:04:b7:ed:52 (oui Unknown), length 28
 14:00:32.090141 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.14 
is-at 7a:a5:71:63:47:94 (oui Unknown), length 28
 14:00:32.090160 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.14 
is-at 02:f9:33:d5:04:0d (oui Unknown), length 28
 14:00:32.090168 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.14 
is-at 9a:a0:46:e4:03:06 (oui Unknown), length 28

  Four different devices are claiming to own the non-existing IP
  address! Looking them up in neutron shows they are all related to
  existing ports on the subnet, but different ones:

 # neutron port-list | grep -e 47fbb8b5-55 -e 46647cca-32 -e e9e2d7c3-7e -e 
9ac24ac1-e1
 | 46647cca-3293-42ea-8ec2-0834e19422fa |   
| fa:16:3e:7d:9c:45 | {"subnet_id": 
"25dbbdc0-f438-4f89-8663-1772f9c7ef36", "ip_address": "192.168.1.8"}   |
 | 47fbb8b5-5549-46e4-850e-bd382375e0f8 |   
| fa:16:3e:fa:df:32 | {"subnet_id": 
"25dbbdc0-f438-4f89-8663-1772f9c7ef36", "ip_address": "192.168.1.7"}   |
 | 9ac24ac1-e157-484e-b6a2-a1dded4731ac |   
| fa:16:3e:2a:80:6b | {"subnet_id": 
"25dbbdc0-f438-4f89-8663-1772f9c7ef36", "ip_address": "192.168.1.15"}  |
 | e9e2d7c3-7e58-4bc2-a25f-d48e658b2d56 |   
| fa:16:3e:0d:a6:0b | {"subnet_id": 
"25dbbdc0-f438-4f89-8663-1772f9c7ef36", "ip_address": "192.168.1.19"}  |

  Environment:

  Host: Ubuntu server 14.04
  Kernel: linux-image-generic-lts-vivid, 3.19.0-39-generic #44~14.04.1-Ubuntu 
SMP Wed Dec 2 10:00:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
  OpenStack

[Yahoo-eng-team] [Bug 1620835] Re: Add timestamp fields for neutron ext resources

2016-11-23 Thread Lana

This document is autogenerated.

** Changed in: openstack-manuals
   Status: New => 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/1620835

Title:
  Add timestamp fields for neutron ext resources

Status in neutron:
  Invalid
Status in openstack-manuals:
  Fix Released

Bug description:
  https://review.openstack.org/312873
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 17b88cd4539cd5fa096115b76fd4a21036395360
  Author: ZhaoBo 
  Date:   Thu May 5 17:16:23 2016 +0800

  Add timestamp fields for neutron ext resources
  
  Propose a new extension named "timestamp_ext" to add timestamp to
  neutron ext resources like 
router/floatingip/security_group/security_group_rule.
  
  APIImpact
  DocImpact: Neutron ext resources now contain 'timestamp' fields like
 'created_at' and 'updated_at'
  Implements: blueprint add-neutron-extension-resource-timestamp
  
  Change-Id: I78b00516e31ce83376d37f57299b2229b6fb8fcf

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1620835/+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 1400814] Re: Libvirt: SMB volume driver

2015-09-03 Thread Lana

** Project changed: openstack-manuals => nova

** Changed in: nova
Milestone: liberty => None

-- 
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/1400814

Title:
  Libvirt: SMB volume driver

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  https://review.openstack.org/131734
  commit 561f8afa5fbc7d94cd65616225597850585d909f
  Author: Lucian Petrut 
  Date:   Tue Oct 28 14:49:26 2014 +0200

  Libvirt: SMB volume driver
  
  Currently, there are Libvirt volume drivers that support
  network-attached file systems such as Gluster or NFS. This patch
  adds a new volume driver in order to support attaching volumes
  hosted on SMB shares.
  
  Co-Authored-By: Gabriel Samfira 
  
  DocImpact
  
  Change-Id: I1db3d2a6d8ee94932348c63cc03698fdefff0b5c
  Implements: blueprint libvirt-smbfs-volume-support

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1400814/+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 1430365] Re: config drive table force_config_drive parameter values do not match Impl

2015-09-02 Thread Lana

** Changed in: openstack-manuals
   Status: Confirmed => Invalid

-- 
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/1430365

Title:
  config drive table force_config_drive parameter  values do not match
  Impl

Status in OpenStack Compute (nova):
  Invalid
Status in openstack-manuals:
  Invalid

Bug description:
  The config drive table [1] describes for the force_config_drive parameter the 
following options: 
  Default: None
  Other Options: always

  But looking at the code [2], only the following values are allowed:
  always, True, False

  What does the current default 'None' mean? Is it really a value? Or
  desribes it the abscense of the parameter?  I could not configure it
  for the force_config_drive option. The abscense of the parameter is
  the same as 'False', so I guess that's the correct default, isn't it?

  The docs should be updated accordingly.

  
  [1] 
https://github.com/openstack/openstack-manuals/blob/master/doc/common/tables/nova-configdrive.xml
  [2] https://github.com/openstack/nova/blob/master/nova/virt/configdrive.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1430365/+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 1477741] Re: Execute _poll_shelved_instances only if shelved_offload_time is > 0

2015-09-02 Thread Lana

** Project changed: openstack-manuals => nova

** Changed in: nova
Milestone: liberty => None

-- 
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/1477741

Title:
  Execute _poll_shelved_instances only if shelved_offload_time is >
  0

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  https://review.openstack.org/201436
  commit abf20cd57023039958091c39f6cdb775c912c9ac
  Author: abhishekkekane 
  Date:   Thu Jul 9 02:58:30 2015 -0700

  Execute _poll_shelved_instances only if shelved_offload_time is > 0
  
  shelved_offload_time -1 means never offload shelved instance. Currently,
  the periodic task "_poll_shelved_instances" changes the vm state from
  SHELVED to SHELVED_OFFLOAD even when the shelved_offload_time is set to 
-1.
  
  Added check in _poll_shelved_instances to offload instances only if
  shelved_offload_time is greater than 0.
  
  DocImpact
  Closes-bug: #1472946
  Change-Id: I55368e961b65a5ca73718fdcd42823680f7cbfa4

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1477741/+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 1381017] Re: PCI passthrough_whitelist configuration option documentation

2015-09-02 Thread Lana

** Project changed: openstack-manuals => nova

** Changed in: nova
Milestone: liberty => None

-- 
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/1381017

Title:
  PCI  passthrough_whitelist  configuration option documentation

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  pci_passthrough_whitelist can be be specified in different ways, but current 
documentation of pci_passthrough_whitelist in nova.conf captured in OpenStack 
Configuration Reference guide, defines only limited option. 
  There is a need to document available options as it is defined in the 
https://github.com/openstack/nova-specs/blob/master/specs/juno/implemented/pci-passthrough-sriov.rst
  specification.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1381017/+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 986980] Re: No documentation about token backends

2015-06-11 Thread Lana

** Changed in: openstack-manuals
   Status: Confirmed = Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/986980

Title:
  No documentation about token backends

Status in OpenStack Identity (Keystone):
  Confirmed
Status in OpenStack Manuals:
  Fix Released

Bug description:
  Documentation lacks of information about token backends: backends
  available, options, memcached configuration for memcached backend,...

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/986980/+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 1307303] [NEW] Make Help link context-sensitive

2014-04-13 Thread Lana

Public bug reported:

For future documentation requirements, can you please modify the
functionality of the Help button in the top menu so that it performs a
lookup of the current page URL, and can return a specific documentation
URL as a result. Thanks.

** 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/1307303

Title:
  Make Help link context-sensitive

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  For future documentation requirements, can you please modify the
  functionality of the Help button in the top menu so that it performs a
  lookup of the current page URL, and can return a specific
  documentation URL as a result. Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1307303/+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 1861493] [NEW] Nova sends an "X-Service-Token" header when "send_service_user_token" is disabled

[Yahoo-eng-team] [Bug 1526818] Re: Install guide: Add arp_ignore (sysctl.conf) to the other IP options

[Yahoo-eng-team] [Bug 1620835] Re: Add timestamp fields for neutron ext resources

[Yahoo-eng-team] [Bug 1400814] Re: Libvirt: SMB volume driver

[Yahoo-eng-team] [Bug 1430365] Re: config drive table force_config_drive parameter values do not match Impl

[Yahoo-eng-team] [Bug 1477741] Re: Execute _poll_shelved_instances only if shelved_offload_time is > 0

[Yahoo-eng-team] [Bug 1381017] Re: PCI passthrough_whitelist configuration option documentation

[Yahoo-eng-team] [Bug 986980] Re: No documentation about token backends

[Yahoo-eng-team] [Bug 1307303] [NEW] Make Help link context-sensitive

9 matches

Site Navigation

Mail list logo

Footer information