[Yahoo-eng-team] [Bug 1717661] [NEW] neutron's test test_create_floatingip_with_specified_ip_address should be executed only for ML2 plugin
Public bug reported: test neutron.tests.tempest.api.admin.test_floating_ips_admin_actions.FloatingIPAdminTestJSON.test_create_floatingip_with_specified_ip_address uses specific feature of ML2 plugin - it tries to detect allocated floating ips through listing of ports. This way doesn't work for non ML2 plugins (ex: Contrail). Contrail plugin doesn't create port for newly allocated floating ip like ML2. When common test's function get_unused_ip returns floating ip that is allocated but not attached then then test case tries to allocate it again it gets HTTP 409. It can be one of these changes to fix this: 1. Do not create a floating ip in setup (it wouldn't help if IP was allocated by someone else) 2. When finding first free ip, also skip over floating ip objects. 3. Use a random available ip address for the test. ** 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/1717661 Title: neutron's test test_create_floatingip_with_specified_ip_address should be executed only for ML2 plugin Status in neutron: New Bug description: test neutron.tests.tempest.api.admin.test_floating_ips_admin_actions.FloatingIPAdminTestJSON.test_create_floatingip_with_specified_ip_address uses specific feature of ML2 plugin - it tries to detect allocated floating ips through listing of ports. This way doesn't work for non ML2 plugins (ex: Contrail). Contrail plugin doesn't create port for newly allocated floating ip like ML2. When common test's function get_unused_ip returns floating ip that is allocated but not attached then then test case tries to allocate it again it gets HTTP 409. It can be one of these changes to fix this: 1. Do not create a floating ip in setup (it wouldn't help if IP was allocated by someone else) 2. When finding first free ip, also skip over floating ip objects. 3. Use a random available ip address for the test. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1717661/+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 1633535] Re: Cinder fails to attach second volume to Nova VM
** Changed in: ec2-api Status: New => 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/1633535 Title: Cinder fails to attach second volume to Nova VM Status in Cinder: In Progress Status in ec2-api: Fix Released Status in Manila: Confirmed Status in OpenStack Compute (nova): New Status in tempest: In Progress Bug description: Cinder fails to attach second volume to Nova VM. This second volume gets "in-use" status, but does not have any attachments. Also, such volume cannot be detached from VM [4]. Test gerrit change [2] proves that commit to Cinder [3] is THE CAUSE of a bug. Also, bug was reproduced even before merge of [3] with "gate-rally-dsvm-cinder" CI job [4], but, I assume, no one has paid attention to this. Local testing shows that IF bug appears then volume never gets attached and list of attachments stays empty. And waiting between 'create' (wait until 'available' status) and 'attach' commands does not help at all. How to reproduce: 1) Create VM 2) Create Volume 3) Attach volume (2) to the VM (1) 4) Create second volume 5) Try attach second volume (4) to VM (1) - it will fail. [Tempest] Also, the fact that Cinder gates passed with [3] means that tempest does not have test that attaches more than one volume to one Nova VM. And it is also tempest bug, that should be addressed. [Manila] In scope of Manila project, one of its drivers is broken - Generic driver that uses Cinder as backend. [1] http://logs.openstack.org/64/386364/1/check/gate-manila-tempest- dsvm-postgres-generic-singlebackend-ubuntu-xenial- nv/eef11b0/logs/screen-m-shr.txt.gz?level=TRACE#_2016-10-14_15_15_19_898 [2] https://review.openstack.org/387915 [3] https://github.com/openstack/cinder/commit/6f174b412696bfa6262a5bea3ac42f45efbbe2ce ( https://review.openstack.org/385122 ) [4] http://logs.openstack.org/22/385122/1/check/gate-rally-dsvm- cinder/b0332e2/rally- plot/results.html.gz#/CinderVolumes.create_snapshot_and_attach_volume/failures To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1633535/+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 1631319] Re: Can't deploy overcloud of Mitaka on CentOS
verified. now it works. ** Changed in: tripleo Status: Triaged => Fix Released -- 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/1631319 Title: Can't deploy overcloud of Mitaka on CentOS Status in OpenStack Identity (keystone): Invalid Status in tripleo: Fix Released Bug description: CentOS 7.2 Undercloud deployed normally by tripleo instructions. keystone - Version : 9.2.1 Release : 0.20161007011449.012bc3d.el7.centos heat-api - Version : 6.0.1 Release : 0.20160829124409.ed46562.el7.centos These numbers tell us that undercloud installed from Mitaka repository But overcloud deploy fails with error - [stack@myhost ~]$ openstack overcloud deploy --templates --neutron-tunnel-types vxlan --neutron-network-type vxlan --ntp-server pool.ntp.org --control-scale 1 --compute-scale 1 --block-storage-scale 3 --control-flavor control --compute-flavor compute --block-storage-flavor block-storage -e overcloud/scaleio-env.yaml Deploying templates in the directory /usr/share/openstack-tripleo-heat-templates ERROR: Authorization failed. keystone logs contains error: domain Default can not be found workaround - change domain from 'Default' to 'default' in heat-api.conf and then overcloud deploy can be started... To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1631319/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: gce-api Importance: Undecided Status: New ** Changed in: gce-api Assignee: (unassigned) => iswarya vakati (v-iswarya) ** Changed in: ec2-api Importance: Undecided => Low ** Changed in: ec2-api Status: New => Confirmed ** Changed in: gce-api Importance: Undecided => Low ** Changed in: gce-api Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: Confirmed Status in gce-api: Confirmed Status in Karbor: New Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in OpenStack Search (Searchlight): New Status in Solum: In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1629726] Re: recompiled pycparser 2.14 breaks Cinder db sync and Nova UTs
** Changed in: ec2-api Status: Confirmed => Fix Released ** Changed in: gce-api 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/1629726 Title: recompiled pycparser 2.14 breaks Cinder db sync and Nova UTs Status in Cinder: Invalid Status in Designate: Confirmed Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in heat: Confirmed Status in Ironic: Fix Released Status in Magnum: Confirmed Status in Manila: Confirmed Status in networking-cisco: Confirmed Status in OpenStack Compute (nova): Confirmed Status in Rally: Confirmed Status in OpenStack DBaaS (Trove): Fix Committed Bug description: http://logs.openstack.org/76/380876/1/check/gate-grenade-dsvm-ubuntu- xenial/3d5e102/logs/grenade.sh.txt.gz#_2016-10-02_23_32_34_069 2016-10-02 23:32:34.069 | + lib/cinder:init_cinder:421 : /usr/local/bin/cinder-manage --config-file /etc/cinder/cinder.conf db sync 2016-10-02 23:32:34.691 | Traceback (most recent call last): 2016-10-02 23:32:34.691 | File "/usr/local/bin/cinder-manage", line 6, in 2016-10-02 23:32:34.691 | from cinder.cmd.manage import main 2016-10-02 23:32:34.691 | File "/opt/stack/old/cinder/cinder/cmd/manage.py", line 77, in 2016-10-02 23:32:34.691 | from cinder import db 2016-10-02 23:32:34.691 | File "/opt/stack/old/cinder/cinder/db/__init__.py", line 20, in 2016-10-02 23:32:34.691 | from cinder.db.api import * # noqa 2016-10-02 23:32:34.691 | File "/opt/stack/old/cinder/cinder/db/api.py", line 43, in 2016-10-02 23:32:34.691 | from cinder.api import common 2016-10-02 23:32:34.691 | File "/opt/stack/old/cinder/cinder/api/common.py", line 30, in 2016-10-02 23:32:34.691 | from cinder import utils 2016-10-02 23:32:34.691 | File "/opt/stack/old/cinder/cinder/utils.py", line 40, in 2016-10-02 23:32:34.691 | from os_brick import encryptors 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/os_brick/encryptors/__init__.py", line 16, in 2016-10-02 23:32:34.691 | from os_brick.encryptors import nop 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/os_brick/encryptors/nop.py", line 16, in 2016-10-02 23:32:34.691 | from os_brick.encryptors import base 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/os_brick/encryptors/base.py", line 19, in 2016-10-02 23:32:34.691 | from os_brick import executor 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/os_brick/executor.py", line 21, in 2016-10-02 23:32:34.691 | from os_brick.privileged import rootwrap as priv_rootwrap 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/os_brick/privileged/__init__.py", line 13, in 2016-10-02 23:32:34.691 | from oslo_privsep import capabilities as c 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/oslo_privsep/capabilities.py", line 73, in 2016-10-02 23:32:34.691 | ffi.cdef(CDEF) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/api.py", line 105, in cdef 2016-10-02 23:32:34.692 | self._cdef(csource, override=override, packed=packed) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/api.py", line 119, in _cdef 2016-10-02 23:32:34.692 | self._parser.parse(csource, override=override, **options) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/cparser.py", line 299, in parse 2016-10-02 23:32:34.692 | self._internal_parse(csource) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/cparser.py", line 304, in _internal_parse 2016-10-02 23:32:34.692 | ast, macros, csource = self._parse(csource) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/cparser.py", line 260, in _parse 2016-10-02 23:32:34.692 | ast = _get_parser().parse(csource) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/cparser.py", line 40, in _get_parser 2016-10-02 23:32:34.692 | _parser_cache = pycparser.CParser() 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/pycparser/c_parser.py", line 87, in __init__ 2016-10-02 23:32:34.692 | outputdir=taboutputdir) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/pycparser/c_lexer.py", line 66, in build 2016-10-02 23:32:34.692 | self.lexer = lex.lex(object=self, **kwargs) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/pycparser/ply/lex.py", line 911, in lex 2016-10-02 23:32:34.692 | lexobj.readtab(lextab, ldict) 2016-10-02 23:32:34.692 | File
[Yahoo-eng-team] [Bug 1629726] Re: recompiled pycparser 2.14 breaks Cinder db sync and Nova UTs
** Also affects: ec2-api Importance: Undecided Status: New ** Also affects: gce-api Importance: Undecided Status: New ** Changed in: ec2-api Importance: Undecided => Critical ** Changed in: ec2-api Status: New => Confirmed ** Changed in: gce-api Importance: Undecided => Critical ** Changed in: gce-api Status: New => Confirmed -- 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/1629726 Title: recompiled pycparser 2.14 breaks Cinder db sync and Nova UTs Status in Cinder: Confirmed Status in Designate: Confirmed Status in ec2-api: Confirmed Status in gce-api: Confirmed Status in heat: Confirmed Status in Ironic: Confirmed Status in Manila: Confirmed Status in OpenStack Compute (nova): Confirmed Status in Rally: Confirmed Status in OpenStack DBaaS (Trove): Confirmed Bug description: http://logs.openstack.org/76/380876/1/check/gate-grenade-dsvm-ubuntu- xenial/3d5e102/logs/grenade.sh.txt.gz#_2016-10-02_23_32_34_069 2016-10-02 23:32:34.069 | + lib/cinder:init_cinder:421 : /usr/local/bin/cinder-manage --config-file /etc/cinder/cinder.conf db sync 2016-10-02 23:32:34.691 | Traceback (most recent call last): 2016-10-02 23:32:34.691 | File "/usr/local/bin/cinder-manage", line 6, in 2016-10-02 23:32:34.691 | from cinder.cmd.manage import main 2016-10-02 23:32:34.691 | File "/opt/stack/old/cinder/cinder/cmd/manage.py", line 77, in 2016-10-02 23:32:34.691 | from cinder import db 2016-10-02 23:32:34.691 | File "/opt/stack/old/cinder/cinder/db/__init__.py", line 20, in 2016-10-02 23:32:34.691 | from cinder.db.api import * # noqa 2016-10-02 23:32:34.691 | File "/opt/stack/old/cinder/cinder/db/api.py", line 43, in 2016-10-02 23:32:34.691 | from cinder.api import common 2016-10-02 23:32:34.691 | File "/opt/stack/old/cinder/cinder/api/common.py", line 30, in 2016-10-02 23:32:34.691 | from cinder import utils 2016-10-02 23:32:34.691 | File "/opt/stack/old/cinder/cinder/utils.py", line 40, in 2016-10-02 23:32:34.691 | from os_brick import encryptors 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/os_brick/encryptors/__init__.py", line 16, in 2016-10-02 23:32:34.691 | from os_brick.encryptors import nop 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/os_brick/encryptors/nop.py", line 16, in 2016-10-02 23:32:34.691 | from os_brick.encryptors import base 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/os_brick/encryptors/base.py", line 19, in 2016-10-02 23:32:34.691 | from os_brick import executor 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/os_brick/executor.py", line 21, in 2016-10-02 23:32:34.691 | from os_brick.privileged import rootwrap as priv_rootwrap 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/os_brick/privileged/__init__.py", line 13, in 2016-10-02 23:32:34.691 | from oslo_privsep import capabilities as c 2016-10-02 23:32:34.691 | File "/usr/local/lib/python2.7/dist-packages/oslo_privsep/capabilities.py", line 73, in 2016-10-02 23:32:34.691 | ffi.cdef(CDEF) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/api.py", line 105, in cdef 2016-10-02 23:32:34.692 | self._cdef(csource, override=override, packed=packed) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/api.py", line 119, in _cdef 2016-10-02 23:32:34.692 | self._parser.parse(csource, override=override, **options) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/cparser.py", line 299, in parse 2016-10-02 23:32:34.692 | self._internal_parse(csource) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/cparser.py", line 304, in _internal_parse 2016-10-02 23:32:34.692 | ast, macros, csource = self._parse(csource) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/cparser.py", line 260, in _parse 2016-10-02 23:32:34.692 | ast = _get_parser().parse(csource) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/cffi/cparser.py", line 40, in _get_parser 2016-10-02 23:32:34.692 | _parser_cache = pycparser.CParser() 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/pycparser/c_parser.py", line 87, in __init__ 2016-10-02 23:32:34.692 | outputdir=taboutputdir) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/pycparser/c_lexer.py", line 66, in build 2016-10-02 23:32:34.692 | self.lexer = lex.lex(object=self, **kwargs) 2016-10-02 23:32:34.692 | File "/usr/local/lib/python2.7/dist-packages/pycparser/ply/lex.py", line
[Yahoo-eng-team] [Bug 1623800] [NEW] Can't add exact count of fixed ips to port (regression)
Public bug reported:
environment: latest devstack. services: nova, glance, keystone, cinder,
neutron, neutron-vpnaas, ec2-api
non-admin project.
we have a scenario when we create a port and then add two fixed ips to it.
Now neutron adds only one fixed_ip to this port but this Monday all was good.
And looks like that now it adds count-1 of passed new fixed_ips.
logs:
2016-09-15 09:13:47.568 14578 DEBUG keystoneclient.session
[req-41aa5bf9-b166-4eb8-b415-cdf039598667 ef0282da2233468c8e715dbfd4385c80
c44a90bf24c14dcbac693c9bb8ac1923 - - -] REQ: curl -g -i --cacert
"/opt/stack/data/ca-bundle.pem" -X GET
http://10.10.0.4:9696/v2.0/ports/0be539d4-ed3c-4bba-8a25-9cb1641335ab.json -H
"User-Agent: python-neutronclient" -H "Accept: application/json" -H
"X-Auth-Token: {SHA1}87af409cdd3b0396fa6954bdc181fddac54d823d"
_http_log_request
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:206
2016-09-15 09:13:47.627 14578 DEBUG keystoneclient.session
[req-41aa5bf9-b166-4eb8-b415-cdf039598667 ef0282da2233468c8e715dbfd4385c80
c44a90bf24c14dcbac693c9bb8ac1923 - - -] RESP: [200] Content-Type:
application/json Content-Length: 735 X-Openstack-Request-Id:
req-4fcc4b7c-09d3-40b6-9332-a3974e422630 Date: Thu, 15 Sep 2016 06:13:47 GMT
Connection: keep-alive
RESP BODY: {"port": {"status": "DOWN", "created_at": "2016-09-15T06:13:46",
"project_id": "c44a90bf24c14dcbac693c9bb8ac1923", "description": "",
"allowed_address_pairs": [], "admin_state_up": true, "network_id":
"93e7bdae-bb7b-4e3e-b33d-e80a561014ea", "tenant_id":
"c44a90bf24c14dcbac693c9bb8ac1923", "extra_dhcp_opts": [], "updated_at":
"2016-09-15T06:13:46", "name": "eni-30152657", "device_owner": "",
"revision_number": 5, "mac_address": "fa:16:3e:12:34:dd",
"port_security_enabled": true, "binding:vnic_type": "normal", "fixed_ips":
[{"subnet_id": "783bf3fa-a077-4a27-9fae-05a7e99fe19e", "ip_address":
"10.7.0.12"}], "id": "0be539d4-ed3c-4bba-8a25-9cb1641335ab", "security_groups":
["2c51d398-1bd1-4084-8063-41bfe57788a4"], "device_id": ""}}
_http_log_response
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:231
2016-09-15 09:13:47.628 14578 DEBUG neutronclient.v2_0.client
[req-41aa5bf9-b166-4eb8-b415-cdf039598667 ef0282da2233468c8e715dbfd4385c80
c44a90bf24c14dcbac693c9bb8ac1923 - - -] GET call to neutron for
http://10.10.0.4:9696/v2.0/ports/0be539d4-ed3c-4bba-8a25-9cb1641335ab.json used
request id req-4fcc4b7c-09d3-40b6-9332-a3974e422630 _append_request_id
/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py:127
2016-09-15 09:13:47.628 14578 DEBUG keystoneclient.session
[req-41aa5bf9-b166-4eb8-b415-cdf039598667 ef0282da2233468c8e715dbfd4385c80
c44a90bf24c14dcbac693c9bb8ac1923 - - -] REQ: curl -g -i --cacert
"/opt/stack/data/ca-bundle.pem" -X PUT
http://10.10.0.4:9696/v2.0/ports/0be539d4-ed3c-4bba-8a25-9cb1641335ab.json -H
"User-Agent: python-neutronclient" -H "Content-Type: application/json" -H
"Accept: application/json" -H "X-Auth-Token:
{SHA1}87af409cdd3b0396fa6954bdc181fddac54d823d" -d '{"port": {"fixed_ips":
[{"subnet_id": "783bf3fa-a077-4a27-9fae-05a7e99fe19e", "ip_address":
"10.7.0.12"}, {"subnet_id": "783bf3fa-a077-4a27-9fae-05a7e99fe19e"},
{"subnet_id": "783bf3fa-a077-4a27-9fae-05a7e99fe19e"}]}}' _http_log_request
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:206
2016-09-15 09:13:48.014 14578 DEBUG keystoneclient.session
[req-41aa5bf9-b166-4eb8-b415-cdf039598667 ef0282da2233468c8e715dbfd4385c80
c44a90bf24c14dcbac693c9bb8ac1923 - - -] RESP: [200] Content-Type:
application/json Content-Length: 816 X-Openstack-Request-Id:
req-0c86f7d1-ce47-4c9e-b842-1aa37c2ca024 Date: Thu, 15 Sep 2016 06:13:48 GMT
Connection: keep-alive
RESP BODY: {"port": {"status": "DOWN", "created_at": "2016-09-15T06:13:46",
"project_id": "c44a90bf24c14dcbac693c9bb8ac1923", "description": "",
"allowed_address_pairs": [], "admin_state_up": true, "network_id":
"93e7bdae-bb7b-4e3e-b33d-e80a561014ea", "tenant_id":
"c44a90bf24c14dcbac693c9bb8ac1923", "extra_dhcp_opts": [], "updated_at":
"2016-09-15T06:13:47", "name": "eni-30152657", "device_owner": "",
"revision_number": 6, "mac_address": "fa:16:3e:12:34:dd",
"port_security_enabled": true, "binding:vnic_type": "normal", "fixed_ips":
[{"subnet_id": "783bf3fa-a077-4a27-9fae-05a7e99fe19e", "ip_address":
"10.7.0.12"}, {"subnet_id": "783bf3fa-a077-4a27-9fae-05a7e99fe19e",
"ip_address": "10.7.0.9"}], "id": "0be539d4-ed3c-4bba-8a25-9cb1641335ab",
"security_groups": ["2c51d398-1bd1-4084-8063-41bfe57788a4"], "device_id": ""}}
_http_log_response
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:231
2016-09-15 09:13:48.015 14578 DEBUG neutronclient.v2_0.client
[req-41aa5bf9-b166-4eb8-b415-cdf039598667 ef0282da2233468c8e715dbfd4385c80
c44a90bf24c14dcbac693c9bb8ac1923 - - -] PUT call to neutron for
http://10.10.0.4:9696/v2.0/ports/0be539d4-ed3c-4bba-8a25-9cb1641335ab.json used
request id req-0c86f7d1-ce47-4c9e-b842-1aa37c2ca024
[Yahoo-eng-team] [Bug 1620248] [NEW] Can't rename instance right after creation (regression)
Public bug reported:
environment: latest devstack
bug come from gating job:
http://logs.openstack.org/66/357766/4/check/gate-functional-neutron-dsvm-ec2api/bd0d68d/logs/
1) instance creation was successful:
2016-09-05 08:46:53.165 995 DEBUG novaclient.v2.client
[req-6bb4aca0-6181-49da-88b7-aa417cae68ba b24eb09f471a4a23910aac1e43b31019
584db43c0b344f628f0c5ec565896f7b - - -] REQ: curl -g -i -X POST
http://127.0.0.1:8774/v2.1/servers -H "User-Agent: python-novaclient" -H
"Content-Type: application/json" -H "Accept: application/json" -H
"X-OpenStack-Nova-API-Version: 2.10" -H "X-Auth-Token:
{SHA1}265ec9d6a4e7c7aa9e817ea0e94a601153eaa6f9" -d '{"server": {"name":
"r-arw7epu0-0", "imageRef": "3adede2d-bcc5-4aba-9cad-759ca6a03bd0",
"availability_zone": "nova", "flavorRef": "16", "max_count": 1, "min_count": 1,
"networks": [{"uuid": "532db1fe-13e1-44b1-8958-1ba64e250580"}]}}'
_http_log_request
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:206
2016-09-05 08:46:53.613 995 DEBUG novaclient.v2.client
[req-6bb4aca0-6181-49da-88b7-aa417cae68ba b24eb09f471a4a23910aac1e43b31019
584db43c0b344f628f0c5ec565896f7b - - -] RESP: [202] Content-Length: 370
Location:
http://127.0.0.1:8774/v2.1/servers/6229c916-7cde-4c76-b26c-a9c13c36a1fc
Content-Type: application/json Openstack-Api-Version: compute 2.10
X-Openstack-Nova-Api-Version: 2.10 Vary: OpenStack-API-Version,
X-OpenStack-Nova-API-Version X-Compute-Request-Id:
req-287852b6-b247-4466-b0c3-2a740c0361e9 Date: Mon, 05 Sep 2016 08:46:53 GMT
Connection: keep-alive
RESP BODY: {"server": {"security_groups": [{"name": "default"}],
"OS-DCF:diskConfig": "MANUAL", "id": "6229c916-7cde-4c76-b26c-a9c13c36a1fc",
"links": [{"href":
"http://127.0.0.1:8774/v2.1/servers/6229c916-7cde-4c76-b26c-a9c13c36a1fc;,
"rel": "self"}, {"href":
"http://127.0.0.1:8774/servers/6229c916-7cde-4c76-b26c-a9c13c36a1fc;, "rel":
"bookmark"}], "adminPass": "***"}}
_http_log_response
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:231
2) but next call to update server has failed.
2016-09-05 08:46:53.614 995 DEBUG novaclient.v2.client
[req-6bb4aca0-6181-49da-88b7-aa417cae68ba b24eb09f471a4a23910aac1e43b31019
584db43c0b344f628f0c5ec565896f7b - - -] POST call to compute for
http://127.0.0.1:8774/v2.1/servers used request id
req-287852b6-b247-4466-b0c3-2a740c0361e9 _log_request_id
/usr/local/lib/python2.7/dist-packages/novaclient/client.py:85
2016-09-05 08:46:53.619 995 DEBUG novaclient.v2.client
[req-6bb4aca0-6181-49da-88b7-aa417cae68ba b24eb09f471a4a23910aac1e43b31019
584db43c0b344f628f0c5ec565896f7b - - -] REQ: curl -g -i -X PUT
http://127.0.0.1:8774/v2.1/servers/6229c916-7cde-4c76-b26c-a9c13c36a1fc -H
"User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept:
application/json" -H "X-OpenStack-Nova-API-Version: 2.10" -H "X-Auth-Token:
{SHA1}265ec9d6a4e7c7aa9e817ea0e94a601153eaa6f9" -d '{"server": {"name":
"i-aca22cdc"}}' _http_log_request
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:206
2016-09-05 08:46:53.647 995 DEBUG novaclient.v2.client
[req-6bb4aca0-6181-49da-88b7-aa417cae68ba b24eb09f471a4a23910aac1e43b31019
584db43c0b344f628f0c5ec565896f7b - - -] RESP: [500] Openstack-Api-Version:
compute 2.10 X-Openstack-Nova-Api-Version: 2.10 Vary: OpenStack-API-Version,
X-OpenStack-Nova-API-Version Content-Type: application/json; charset=UTF-8
Content-Length: 225 X-Compute-Request-Id:
req-39cece3c-1787-4226-a661-61adbf34eec1 Date: Mon, 05 Sep 2016 08:46:53 GMT
Connection: keep-alive
RESP BODY: {"computeFault": {"message": "Unexpected API Error. Please report
this at http://bugs.launchpad.net/nova/ and attach the Nova API log if
possible.\n",
"code": 500}}
logs from nova-api:
2016-09-05 08:46:53.626 23353 DEBUG nova.api.openstack.wsgi
[req-39cece3c-1787-4226-a661-61adbf34eec1 user-62ad2e65 project-bd1b71ed]
Action: 'update', calling method: >, body: {"server": {"name": "i-aca22cdc"}} _process_stack
/opt/stack/new/nova/nova/api/openstack/wsgi.py:633
2016-09-05 08:46:53.627 23353 DEBUG nova.compute.api
[req-39cece3c-1787-4226-a661-61adbf34eec1 user-62ad2e65 project-bd1b71ed]
[instance: 6229c916-7cde-4c76-b26c-a9c13c36a1fc] Fetching instance by UUID get
/opt/stack/new/nova/nova/compute/api.py:2209
2016-09-05 08:46:53.643 23353 ERROR nova.api.openstack.extensions
[req-39cece3c-1787-4226-a661-61adbf34eec1 user-62ad2e65 project-bd1b71ed]
Unexpected exception in API method
2016-09-05 08:46:53.643 23353 ERROR nova.api.openstack.extensions Traceback
(most recent call last):
2016-09-05 08:46:53.643 23353 ERROR nova.api.openstack.extensions File
"/opt/stack/new/nova/nova/api/openstack/extensions.py", line 338, in wrapped
2016-09-05 08:46:53.643 23353 ERROR nova.api.openstack.extensions return
f(*args, **kwargs)
2016-09-05 08:46:53.643 23353 ERROR nova.api.openstack.extensions File
"/opt/stack/new/nova/nova/api/validation/__init__.py", line 73, in wrapper
2016-09-05
[Yahoo-eng-team] [Bug 1618013] [NEW] metadata route is absent and metadata server unavailable for instance with network w/o gateway (regression)
Public bug reported: ubuntu 14.04 latest devstack (28.08.2016) enabled services: nova, glance, cinder, keystone, horizon, neutron, neutron-vpnaas, ec2-api steps to reproduce: 0) source demo credentials 1) create network 2) create subnet without gateway 3) boot instance from cirros image 4) run vnc console 5) run 'route -n': Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 10.10.0.0 10.10.2.1 255.255.0.0 UG0 00 eth0 10.10.2.0 0.0.0.0 255.255.255.0 U 0 00 eth0 6) run 'curl http://169.254.169.254/latest/' curl: (7) Failed to connect to 169.254.169.254: Network is unreachable if user runs instance with predefined network that all works well: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.10.1.1 0.0.0.0 UG0 00 eth0 10.10.0.0 10.10.1.1 255.255.0.0 UG0 00 eth0 10.10.1.0 0.0.0.0 255.255.255.0 U 0 00 eth0 169.254.169.254 10.10.1.1 255.255.255.255 UGH 0 00 eth0 according to gating jobs it was broken between "Aug 25 2:05 PM" (last check pipeline - https://review.openstack.org/#/c/360230/) and "Aug 26 1:05 AM" (patch 4 first check pipeline - https://review.openstack.org/#/c/357766/) ** Affects: nova 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/1618013 Title: metadata route is absent and metadata server unavailable for instance with network w/o gateway (regression) Status in OpenStack Compute (nova): New Bug description: ubuntu 14.04 latest devstack (28.08.2016) enabled services: nova, glance, cinder, keystone, horizon, neutron, neutron-vpnaas, ec2-api steps to reproduce: 0) source demo credentials 1) create network 2) create subnet without gateway 3) boot instance from cirros image 4) run vnc console 5) run 'route -n': Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 10.10.0.0 10.10.2.1 255.255.0.0 UG0 00 eth0 10.10.2.0 0.0.0.0 255.255.255.0 U 0 00 eth0 6) run 'curl http://169.254.169.254/latest/' curl: (7) Failed to connect to 169.254.169.254: Network is unreachable if user runs instance with predefined network that all works well: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.10.1.1 0.0.0.0 UG0 00 eth0 10.10.0.0 10.10.1.1 255.255.0.0 UG0 00 eth0 10.10.1.0 0.0.0.0 255.255.255.0 U 0 00 eth0 169.254.169.254 10.10.1.1 255.255.255.255 UGH 0 00 eth0 according to gating jobs it was broken between "Aug 25 2:05 PM" (last check pipeline - https://review.openstack.org/#/c/360230/) and "Aug 26 1:05 AM" (patch 4 first check pipeline - https://review.openstack.org/#/c/357766/) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1618013/+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 1612953] [NEW] fail to boot instance with port of specfic subnet
Public bug reported:
Environment: Devstack from master(12.08.2016) on Ubuntu 14.04. services:
nova, neutron, swift, glance, keystone, cinder, ec2-api
steps to reproduce:
use any credentials, find you project id
1) create network
neutron net-create --tenant-id {{PROJECT_ID}} pnet
2) create SPECIFIC subnet
neutron subnet-create --tenant-id {{PROJECT_ID}} --ip_version 4 --name psubnet
--host-route destination=10.17.0.0/20,nexthop=10.17.0.1 --no-gateway
{{NETWORK_ID}} 10.17.0.0/24
3) create port
neutron port-create {{NETWORK_ID}}
4) boot instance
nova boot --flavor 1 --image "cirros-0.3.4-x86_64-uec" --nic
port-id={{PORT_ID}} ttt
-> instance boot fails.
nova compute logs:
[req-26223e37-ddec-4f82-937d-efb1bdce0936 admin admin] [instance:
65e82e51-cbdb-4b1f-9ed2-77789a92a90a] Instance failed to spawn
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] Traceback (most recent call
last):
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/compute/manager.py", line 2075, in _build_resources
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] yield resources
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/compute/manager.py", line 1919, in _build_and_run_instance
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a]
block_device_info=block_device_info)
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 2658, in spawn
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] write_to_disk=True)
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 4693, in _get_guest_xml
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] context)
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 4525, in _get_guest_config
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] flavor, virt_type,
self._host)
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/virt/libvirt/vif.py", line 507, in get_config
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] vif_obj =
os_vif_util.nova_to_osvif_vif(vif)
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/network/os_vif_util.py", line 371, in nova_to_osvif_vif
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] vifobj = func(vif)
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/network/os_vif_util.py", line 269, in
_nova_to_osvif_vif_ovs
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a]
bridge_name=_get_hybrid_bridge_name(vif))
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/network/os_vif_util.py", line 239, in _get_vif_instance
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a]
network=_nova_to_osvif_network(vif['network']),
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/network/os_vif_util.py", line 205, in
_nova_to_osvif_network
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a]
subnets=_nova_to_osvif_subnets(network['subnets']))
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/network/os_vif_util.py", line 191, in
_nova_to_osvif_subnets
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a]
objects=[_nova_to_osvif_subnet(subnet) for subnet in subnets])
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/network/os_vif_util.py", line 173, in
_nova_to_osvif_subnet
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a]
routes=_nova_to_osvif_routes(subnet['routes']))
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/network/os_vif_util.py", line 157, in
_nova_to_osvif_routes
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a]
objects=[_nova_to_osvif_route(route) for route in routes])
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/opt/stack/nova/nova/network/os_vif_util.py", line 139, in _nova_to_osvif_route
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a]
interface=route['interface'])
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line
307, in __init__
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] setattr(self, key,
kwargs[key])
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line
72, in setter
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] field_value =
field.coerce(self, name, value)
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/fields.py", line
193, in coerce
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] return self._null(obj,
attr)
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a] File
"/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/fields.py", line
171, in _null
[instance: 65e82e51-cbdb-4b1f-9ed2-77789a92a90a]
[Yahoo-eng-team] [Bug 1607350] [NEW] floating-ip info doesn't contaion information about instance if associated with nova network
Public bug reported: [Summary] floating ip info does not contain information about associated instance if nova-network is used. behaviour was changed between 11.05.16 and 21.06.16 [Topo] devstack all-in-one node libvirt+qemu nova-network [Description and expect result] floating ip info contains information about associated instance as in previous releases. [Reproduceable or not] reproduceable [Recreate Steps] 0) source any credentials. Result is the same for demo credentials of devstack (user=demo project=demo) and for admin credentials. 1) boot instance nova boot --image cirros-0.3.4-x86_64-uec --flavor 1 ttt 2) create floating ip nova floating-ip-create 3) associate floating-ip nova floating-ip-associate ttt 172.24.4.1 4) list intsances nova list +--+--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+--+ | 8ad61db0-f388-4bc7-bfbd-728782a5b505 | ttt | ACTIVE | - | Running | private=10.0.0.4, 172.24.4.1 | +--+--+++-+--+ 5) list floating ips nova floating-ip-list +++---+--++ | Id | IP | Server Id | Fixed IP | Pool | +++---+--++ | 1 | 172.24.4.1 | - | -| public | +++---+--++ [Root cause anlyze or debug inf] - database contains information about floating ip and record has a correct id of fixed ip - database contains informtaion about fixed ip and record has a correct instance uuid nova 'os-floating-ips' rest api calls network_api.get_floating_ips_by_project it calls objects.FloatingIPList.get_by_project it retrieves floating ips from DB and calls obj_base.obj_make_list for each record obj_make_list calls _from_db_object of passed type and creates FloatingIP object _from_db_object takes 'fixed_ip' as expected attributes but only FloatingIP.get_by_id passes it. ** Affects: nova 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/1607350 Title: floating-ip info doesn't contaion information about instance if associated with nova network Status in OpenStack Compute (nova): New Bug description: [Summary] floating ip info does not contain information about associated instance if nova-network is used. behaviour was changed between 11.05.16 and 21.06.16 [Topo] devstack all-in-one node libvirt+qemu nova-network [Description and expect result] floating ip info contains information about associated instance as in previous releases. [Reproduceable or not] reproduceable [Recreate Steps] 0) source any credentials. Result is the same for demo credentials of devstack (user=demo project=demo) and for admin credentials. 1) boot instance nova boot --image cirros-0.3.4-x86_64-uec --flavor 1 ttt 2) create floating ip nova floating-ip-create 3) associate floating-ip nova floating-ip-associate ttt 172.24.4.1 4) list intsances nova list +--+--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+--+ | 8ad61db0-f388-4bc7-bfbd-728782a5b505 | ttt | ACTIVE | - | Running | private=10.0.0.4, 172.24.4.1 | +--+--+++-+--+ 5) list floating ips nova floating-ip-list +++---+--++ | Id | IP | Server Id | Fixed IP | Pool | +++---+--++ | 1 | 172.24.4.1 | - | -| public | +++---+--++ [Root cause anlyze or debug inf] - database contains information about floating ip and record has a correct id of fixed ip - database contains informtaion about fixed ip and record has a correct instance uuid nova 'os-floating-ips' rest api calls network_api.get_floating_ips_by_project it calls objects.FloatingIPList.get_by_project it retrieves floating ips from DB and calls obj_base.obj_make_list for each record obj_make_list calls _from_db_object of passed type and creates FloatingIP object _from_db_object takes 'fixed_ip' as expected attributes but only FloatingIP.get_by_id passes it.
[Yahoo-eng-team] [Bug 1528805] [NEW] create_ipsec_site_connection call failed because of code inconsistency
Public bug reported:
EC2-API gating checks vpn functionality and it is broken two days due to
vpn-ass.
gating enables vpnass plugin and neutron
gating fails on call - "neutron.create_ipsec_site_connection":
REQ: curl -g -i -X POST http://127.0.0.1:9696/v2.0/vpn/ipsec-site-
connections.json -H "User-Agent: python-neutronclient" -H "Content-Type:
application/json" -H "Accept: application/json" -H "X-Auth-Token:
{SHA1}88227c79fef8266afa89bd559e6f92bb99dd17df" -d
'{"ipsec_site_connection": {"ikepolicy_id": "9f00451d-
aaa8-4465-97f1-f45b6890771e", "peer_cidrs": ["172.16.25.0/24"], "mtu":
1427, "ipsecpolicy_id": "31b17d19-a898-472b-8944-fa34321b67e5",
"vpnservice_id": "7586b8d4-1c1e-49dd-91cc-e1055138ba6d", "psk":
"p.Hu0SlBXoSd8sF1WV.QDSy32sVCjKON", "peer_address": "198.51.100.77",
"peer_id": "198.51.100.77", "initiator": "response-only", "name": "vpn-
360307d8/subnet-031705ee"}}' _http_log_request /usr/local/lib/python2.7
/dist-packages/keystoneclient/session.py:198
it takes exception from neutron and netron logs are:
2015-12-22 21:28:38.620 DEBUG neutron.api.v2.base
[req-86bbd8b1-af64-4d82-86d4-15daa40a2a8f user-29edecd6 project-3a1e0ba2]
Request body: {u'ipsec_site_connection': {u'psk':
u'p.Hu0SlBXoSd8sF1WV.QDSy32sVCjKON', u'peer_cidrs': [u'172.16.25.0/24'],
u'vpnservice_id': u'7586b8d4-1c1e-49dd-91cc-e1055138ba6d', u'initiator':
u'response-only', u'mtu': 1427, u'ikepolicy_id':
u'9f00451d-aaa8-4465-97f1-f45b6890771e', u'ipsecpolicy_id':
u'31b17d19-a898-472b-8944-fa34321b67e5', u'peer_address': u'198.51.100.77',
u'peer_id': u'198.51.100.77', u'name': u'vpn-360307d8/subnet-031705ee'}}
prepare_request_body /opt/stack/new/neutron/neutron/api/v2/base.py:645
2015-12-22 21:28:38.620 ERROR neutron.api.v2.resource
[req-86bbd8b1-af64-4d82-86d4-15daa40a2a8f user-29edecd6 project-3a1e0ba2]
create failed
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource Traceback (most
recent call last):
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 83, in resource
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource result =
method(request=request, **args)
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 147, in wrapper
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource ectxt.value =
e.inner_exc
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 204, in
__exit__
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 137, in wrapper
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource return f(*args,
**kwargs)
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 414, in create
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource
allow_bulk=self._allow_bulk)
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 680, in
prepare_request_body
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource
attributes.convert_value(attr_info, res_dict, webob.exc.HTTPBadRequest)
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/attributes.py", line 919, in
convert_value
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource res =
validators[rule](res_dict[attr], attr_vals['validate'][rule])
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron-vpnaas/neutron_vpnaas/extensions/vpnaas.py", line 167,
in _validate_subnet_list_or_none
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource
attr._validate_subnet_list(data, key_specs)
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource AttributeError:
'module' object has no attribute '_validate_subnet_list'
2015-12-22 21:28:38.620 16707 ERROR neutron.api.v2.resource
2015-12-22 21:28:38.625 INFO neutron.wsgi
[req-86bbd8b1-af64-4d82-86d4-15daa40a2a8f user-29edecd6 project-3a1e0ba2]
127.0.0.1 - - [22/Dec/2015 21:28:38] "POST
/v2.0/vpn/ipsec-site-connections.json HTTP/1.1" 500 383 0.092068
** 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/1528805
Title:
create_ipsec_site_connection call failed because of code inconsistency
Status in neutron:
New
Bug description:
EC2-API gating checks vpn functionality and it is broken two days due to
vpn-ass.
gating enables vpnass plugin and neutron
gating fails on call - "neutron.create_ipsec_site_connection":
REQ:
[Yahoo-eng-team] [Bug 1528031] [NEW] 'NetworkNotFound' exception during listing ports
Public bug reported: There is a problem - when I run tests in parallel then one/two can fail. As I see in logs one thread is deleting network while second thread is listing all ports. And second thread get exception 'NetworkNotFound'. Part of neutron service logs is: 2015-12-18 06:29:05.151 INFO neutron.wsgi [req-4d303e7d-ae31-47b5-a644-552fceeb03ef user-0a50ad96 project-ce45a55a] 52.90.96.102 - - [18/Dec/2015 06:29:05] "DELETE /v2.0/networks/d2d2481a-4c20-452f-8088-6e6815694ac0.json HTTP/1.1" 204 173 0.426808 2015-12-18 06:29:05.173 ERROR neutron.policy [req-a406e696-6791-4345-8b04-215ca313ea67 user-0a50ad96 project-ce45a55a] Policy check error while calling >! 2015-12-18 06:29:05.173 22048 ERROR neutron.policy Traceback (most recent call last): 2015-12-18 06:29:05.173 22048 ERROR neutron.policy File "/opt/stack/neutron/neutron/policy.py", line 258, in __call__ 2015-12-18 06:29:05.173 22048 ERROR neutron.policy fields=[parent_field]) 2015-12-18 06:29:05.173 22048 ERROR neutron.policy File "/opt/stack/neutron/neutron/plugins/ml2/plugin.py", line 713, in get_network 2015-12-18 06:29:05.173 22048 ERROR neutron.policy result = super(Ml2Plugin, self).get_network(context, id, None) 2015-12-18 06:29:05.173 22048 ERROR neutron.policy File "/opt/stack/neutron/neutron/db/db_base_plugin_v2.py", line 385, in get_network 2015-12-18 06:29:05.173 22048 ERROR neutron.policy network = self._get_network(context, id) 2015-12-18 06:29:05.173 22048 ERROR neutron.policy File "/opt/stack/neutron/neutron/db/db_base_plugin_common.py", line 188, in _get_network 2015-12-18 06:29:05.173 22048 ERROR neutron.policy raise n_exc.NetworkNotFound(net_id=id) 2015-12-18 06:29:05.173 22048 ERROR neutron.policy NetworkNotFound: Network d2d2481a-4c20-452f-8088-6e6815694ac0 could not be found. 2015-12-18 06:29:05.173 22048 ERROR neutron.policy 2015-12-18 06:29:05.175 INFO neutron.api.v2.resource [req-a406e696-6791-4345-8b04-215ca313ea67 user-0a50ad96 project-ce45a55a] index failed (client error): Network d2d2481a-4c20-452f-8088-6e6815694ac0 could not be found. 2015-12-18 06:29:05.175 INFO neutron.wsgi [req-a406e696-6791-4345-8b04-215ca313ea67 user-0a50ad96 project-ce45a55a] 52.90.96.102 - - [18/Dec/2015 06:29:05] "GET /v2.0/ports.json?tenant_id=63f912ca152048c6a6b375784d90bd37 HTTP/1.1" 404 359 0.311871 Answer from Kevin Benton (in mailing list): Ah, I believe what is happening is that the network is being deleted after the port has been retrieved from the database during the policy check. The policy check retrieves the port's network to be able to enforce the network_owner lookup: https://github.com/openstack/neutron/blob/master/etc/policy.json#L6 So order of events seems to be: port list API call received ports retrieved from db network delete request is processed ports processed by policy engine policy engine triggers network lookup and hits 404 This appears to be a legitimate bug. Maybe we need to find a way to cache the network at port retrieval time for the policy engine. ** 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/1528031 Title: 'NetworkNotFound' exception during listing ports Status in neutron: New Bug description: There is a problem - when I run tests in parallel then one/two can fail. As I see in logs one thread is deleting network while second thread is listing all ports. And second thread get exception 'NetworkNotFound'. Part of neutron service logs is: 2015-12-18 06:29:05.151 INFO neutron.wsgi [req-4d303e7d-ae31-47b5-a644-552fceeb03ef user-0a50ad96 project-ce45a55a] 52.90.96.102 - - [18/Dec/2015 06:29:05] "DELETE /v2.0/networks/d2d2481a-4c20-452f-8088-6e6815694ac0.json HTTP/1.1" 204 173 0.426808 2015-12-18 06:29:05.173 ERROR neutron.policy [req-a406e696-6791-4345-8b04-215ca313ea67 user-0a50ad96 project-ce45a55a] Policy check error while calling >! 2015-12-18 06:29:05.173 22048 ERROR neutron.policy Traceback (most recent call last): 2015-12-18 06:29:05.173 22048 ERROR neutron.policy File "/opt/stack/neutron/neutron/policy.py", line 258, in __call__ 2015-12-18 06:29:05.173 22048 ERROR neutron.policy fields=[parent_field]) 2015-12-18 06:29:05.173 22048 ERROR neutron.policy File "/opt/stack/neutron/neutron/plugins/ml2/plugin.py", line 713, in get_network 2015-12-18 06:29:05.173 22048 ERROR neutron.policy result = super(Ml2Plugin, self).get_network(context, id, None) 2015-12-18 06:29:05.173 22048 ERROR neutron.policy File "/opt/stack/neutron/neutron/db/db_base_plugin_v2.py", line 385, in get_network 2015-12-18 06:29:05.173 22048 ERROR neutron.policy network = self._get_network(context, id) 2015-12-18 06:29:05.173 22048 ERROR neutron.policy File "/opt/stack/neutron/neutron/db/db_base_plugin_common.py", line 188, in _get_network
[Yahoo-eng-team] [Bug 1370177] Re: Lack of EC2 image attributes for volume backed snapshot.
** Changed in: ec2-api Status: Fix Committed => 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/1370177 Title: Lack of EC2 image attributes for volume backed snapshot. Status in ec2-api: Fix Released Status in OpenStack Compute (nova): Fix Released Bug description: For EBS images AWS returns device names, volume sizes, delete on termination flags in block device mapping structure. $ euca-describe-images ami-d13845e1 IMAGE ami-d13845e1amazon/amzn-ami-hvm-2014.03.2.x86_64-ebsamazon available public x86_64 machine ebs hvm xen BLOCKDEVICEMAPPING/dev/xvda snap-d15cde24 8 true The same in xml form: /dev/xvda snap-d15cde24 8 true standard But Nova didn't do it now: $ euca-describe-images ami-000a IMAGE ami-000aNone (sn-in)ef3ddd7aa4b24cda974200baef02730b available private machine aki-0002ari-0003 instance-store BLOCKDEVICEMAPPINGsnap-0005 The same in xml form: snap-0005 NB. In Grizzly device names and delete on termination flags was returned. It was changed by https://github.com/openstack/nova/commit/33e3d4c6b9e0b11500fe47d861110be1c1981572 Now these attributes are not stored in instance snapshots, so there is no way to output them. Device name is most critical attribute. Because there is another one compatibility issue (see https://bugs.launchpad.net/nova/+bug/1370250): Nova isn't able to adjust attributes of volume being created at instance launch stage. For example in AWS we can change volume size and delete on termination flag of a device by set new values in parameters of run instance command. To identify the device in image block device mapping we use device name. For example: euca-run-instances ... -b /dev/vda=:100 runs an instance with vda device increased to 100 GB. Thus if we haven't device names in images, we haven't a chance to fix this compatibility problem. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1370177/+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 1370250] Re: Can not set volume attributes at instance launch by EC2 API
** Changed in: ec2-api Status: Fix Committed => 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/1370250 Title: Can not set volume attributes at instance launch by EC2 API Status in ec2-api: Fix Released Status in OpenStack Compute (nova): Fix Released Bug description: AWS allows to change block device attributes (such as volume size, delete on termination behavior, existence) at instance launch. For example, image xxx has devices: vda, size 10, delete on termination vdb, size 100, delete on termination vdc, size 100, delete on termination We can run an instance by euca-run-instances ... xxx -b /dev/vda=:20 -b /dev/vdb=::false -b /dev/vdc=none to get the instance with devices: vda, size 20, delete on termination vdb, size 100, not delete on termination For Nova we get now: $ euca-run-instances --instance-type m1.nano -b /dev/vda=::true ami-000a euca-run-instances: error (InvalidBDMFormat): Block Device Mapping is Invalid: Unrecognized legacy format. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1370250/+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 1273983] Re: Pagination not implemented for DescribeTags
** Changed in: ec2-api Status: Fix Committed => 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/1273983 Title: Pagination not implemented for DescribeTags Status in ec2-api: Fix Released Status in OpenStack Compute (nova): Won't Fix Bug description: Amazon's API tells that it has MaxResults and NextToken tags for pagination. There is no such thing in our API http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeTags.html To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1273983/+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 1370901] Re: Nova EC2 doesn't create empty volume while launching an instance
** Changed in: ec2-api Status: Fix Committed => 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/1370901 Title: Nova EC2 doesn't create empty volume while launching an instance Status in ec2-api: Fix Released Status in OpenStack Compute (nova): Won't Fix Bug description: AWS is able to create and attach a new empty volume while launching an instance. See http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-RunInstances.html: --- To create an empty Amazon EBS volume, omit the snapshot ID and specify a volume size instead. For example: "/dev/sdh=:20". --- This can be set by run_instances parameters, and by image block device mapping structure. But Nova EC2 isn't able to do this: $ euca-run-instances --instance-type m1.nano ami-0001 --block-device-mapping /dev/vdd=:1 euca-run-instances: error (InvalidBDMFormat): Block Device Mapping is Invalid: Unrecognized legacy format. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1370901/+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 829880] Re: object store doesn't like key with '/'
** Changed in: ec2-api
Status: Fix Committed => 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/829880
Title:
object store doesn't like key with '/'
Status in ec2-api:
Fix Released
Status in pyjuju:
Fix Released
Status in OpenStack Compute (nova):
Won't Fix
Status in juju package in Ubuntu:
Fix Released
Bug description:
It looks like it should be correct given that its taking a hash of the
key for the filename in the bucket dir, but it looks like its running
afoul before it gets there.. sample script to reproduce (python+boto)
against nova-objectstore (s3server.py)
import boto
import os
from boto.s3.connection import S3Connection, OrdinaryCallingFormat
s3 = S3Connection(
aws_access_key_id=os.environ["EC2_ACCESS_KEY"],
aws_secret_access_key=os.environ["EC2_SECRET_KEY"],
host = os.environ["S3_URL"][len("http://;):],
is_secure = False,
calling_format=OrdinaryCallingFormat())
bucket = s3.create_bucket("es-testing-123")
print "new key"
key = bucket.new_key("abc.txt")
key.set_contents_from_string("abcdef")
print "new nested key"
key = bucket.new_key("zoo/abc.txt")
key.set_contents_from_string("abcdef")
"""
Fails with
S3ResponseError: 404 Not Found
404 Not Found
The resource could not be found.
"""
To manage notifications about this bug go to:
https://bugs.launchpad.net/ec2-api/+bug/829880/+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 1513782] [NEW] API response time degradation
Public bug reported: We found response time degradation in list operations for network objects. Such degradation we found in our rally jobs. This job works in devstack with 'fake_virt' libvirt driver. One part of this job creates 200 servers with floating ip and lists them and their objects. I saw that 18.08.2015 response times was good [1] but 21.08.2015 they became bad [2]. Right now response times still bad [3]... I suggest that this is a neutron problem because we have several tests that measure different aspects. For example, listing of regions and images have same times as in the past. But degradation of addresses` listing is in ~ten times: was (for 200 servers): 0.719 seconds now (for 100 servers): 5.039 seconds subnets: 1.358 vs 5.606 network_interfaces: 1.292 vs 10.298 Also I've asked in mailing list [4] but there was no sensible answer... [1] http://logs.openstack.org/13/211613/6/experimental/ec2-api-rally-dsvm-fakevirt/fac263e/ [2] http://logs.openstack.org/74/213074/7/experimental/ec2-api-rally-dsvm-fakevirt/91d0675/ [3] http://logs.openstack.org/74/213074/7/experimental/ec2-api-rally-dsvm-fakevirt/91d0675/rally-plot/detailed.txt.gz [4] http://lists.openstack.org/pipermail/openstack-dev/2015-September/073577.html ** Affects: neutron Importance: Undecided Status: New ** Description changed: We found response time degradation in list operations for network objects. Such degradation we found in our rally jobs. This job works in devstack with 'fake_virt' libvirt driver. One part of this job creates 200 servers with floating ip and lists them and their objects. I saw that 18.08.2015 response times was good [1] but 21.08.2015 they became bad [2]. Right now response times still bad [3]... I suggest that this is a neutron problem because we have several tests that measure different aspects. For example, listing of regions and images have same times as in the past. But degradation of addresses` listing is in ~ten times: was (for 200 servers): 0.719 seconds now (for 100 servers): 5.039 seconds subnets: 1.358 vs 5.606 network_interfaces: 1.292 vs 10.298 + Also I've asked in mailing list [4] but there was no sensible answer... [1] http://logs.openstack.org/13/211613/6/experimental/ec2-api-rally-dsvm-fakevirt/fac263e/ [2] http://logs.openstack.org/74/213074/7/experimental/ec2-api-rally-dsvm-fakevirt/91d0675/ [3] http://logs.openstack.org/74/213074/7/experimental/ec2-api-rally-dsvm-fakevirt/91d0675/rally-plot/detailed.txt.gz + [4] http://lists.openstack.org/pipermail/openstack-dev/2015-September/073577.html -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1513782 Title: API response time degradation Status in neutron: New Bug description: We found response time degradation in list operations for network objects. Such degradation we found in our rally jobs. This job works in devstack with 'fake_virt' libvirt driver. One part of this job creates 200 servers with floating ip and lists them and their objects. I saw that 18.08.2015 response times was good [1] but 21.08.2015 they became bad [2]. Right now response times still bad [3]... I suggest that this is a neutron problem because we have several tests that measure different aspects. For example, listing of regions and images have same times as in the past. But degradation of addresses` listing is in ~ten times: was (for 200 servers): 0.719 seconds now (for 100 servers): 5.039 seconds subnets: 1.358 vs 5.606 network_interfaces: 1.292 vs 10.298 Also I've asked in mailing list [4] but there was no sensible answer... [1] http://logs.openstack.org/13/211613/6/experimental/ec2-api-rally-dsvm-fakevirt/fac263e/ [2] http://logs.openstack.org/74/213074/7/experimental/ec2-api-rally-dsvm-fakevirt/91d0675/ [3] http://logs.openstack.org/74/213074/7/experimental/ec2-api-rally-dsvm-fakevirt/91d0675/rally-plot/detailed.txt.gz [4] http://lists.openstack.org/pipermail/openstack-dev/2015-September/073577.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1513782/+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 1504235] [NEW] Can't run instance with non-ascii symbols in user_data
Public bug reported:
Gating of ec2api project has a test that runs instance with user data that
contains non-ascii symbols under python 2.7.
And now it fails because of fix bug https://bugs.launchpad.net/nova/+bug/1502583
Version: master branch
stack trace from nova compute [1]:
2015-10-08 16:50:00.267 ERROR nova.compute.manager
[req-eb417914-b76f-42b3-a825-7e86785d2bbe user-9eea8ece project-e7ccb1a9]
[instance: 529a79f0-6707-4882-af0f-63a5af1fa111] Instance failed to spawn
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] Traceback (most recent call last):
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] File
"/opt/stack/new/nova/nova/compute/manager.py", line 2172, in _build_resources
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] yield resources
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] File
"/opt/stack/new/nova/nova/compute/manager.py", line 2019, in
_build_and_run_instance
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] block_device_info=block_device_info)
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] File
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 2437, in spawn
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] admin_pass=admin_password)
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] File
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 2942, in _create_image
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] cdb.make_drive(configdrive_path)
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] File
"/opt/stack/new/nova/nova/virt/configdrive.py", line 163, in make_drive
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] self._write_md_files(tmpdir)
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] File
"/opt/stack/new/nova/nova/virt/configdrive.py", line 98, in _write_md_files
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] self._add_file(basedir, data[0],
data[1])
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] File
"/opt/stack/new/nova/nova/virt/configdrive.py", line 90, in _add_file
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] f.write(data.encode('utf-8'))
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] UnicodeDecodeError: 'ascii' codec can't
decode byte 0xd0 in position 36: ordinal not in range(128)
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111]
[1] http://logs.openstack.org/50/232550/1/check/gate-functional-neutron-
dsvm-ec2api/2eda628/logs/screen-n-cpu.txt.gz#_2015-10-08_16_50_00_267
** Affects: nova
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/1504235
Title:
Can't run instance with non-ascii symbols in user_data
Status in OpenStack Compute (nova):
New
Bug description:
Gating of ec2api project has a test that runs instance with user data that
contains non-ascii symbols under python 2.7.
And now it fails because of fix bug
https://bugs.launchpad.net/nova/+bug/1502583
Version: master branch
stack trace from nova compute [1]:
2015-10-08 16:50:00.267 ERROR nova.compute.manager
[req-eb417914-b76f-42b3-a825-7e86785d2bbe user-9eea8ece project-e7ccb1a9]
[instance: 529a79f0-6707-4882-af0f-63a5af1fa111] Instance failed to spawn
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] Traceback (most recent call last):
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] File
"/opt/stack/new/nova/nova/compute/manager.py", line 2172, in _build_resources
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] yield resources
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager [instance:
529a79f0-6707-4882-af0f-63a5af1fa111] File
"/opt/stack/new/nova/nova/compute/manager.py", line 2019, in
_build_and_run_instance
2015-10-08 16:50:00.267 32724 ERROR nova.compute.manager
[Yahoo-eng-team] [Bug 1473042] Re: s3 token authentication doesn't support v4 protocol
** 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 Keystone. https://bugs.launchpad.net/bugs/1473042 Title: s3 token authentication doesn't support v4 protocol Status in Keystone: In Progress Status in keystonemiddleware: In Progress Bug description: Amazon has several versions of signature for requests. Now s3_token middleware supports only first s3 signature version. It will be good if s3_token middleware will support v4 version. http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html http://docs.aws.amazon.com/AmazonS3/latest/API/bucket-policy-s3-sigv4-conditions.html openstack/nova and stackforge/ec2-api projects don't have authenticatoin, so these projects can use keystone middleware if it will has v4 auth. Also stackforge/swift3 now uses keystone middleware and has a bug https://bugs.launchpad.net/swift3/+bug/1411078 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1473042/+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 1398357] Re: Add support for EC2 API : ec2-reset-snapshot-attribute
cinder doesn't allow to modify permissions for snapshots/volumes. These objects can be seen only by owner or admin. ** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Opinion ** Changed in: ec2-api Importance: Undecided = Wishlist -- 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/1398357 Title: Add support for EC2 API : ec2-reset-snapshot-attribute Status in ec2-api: Opinion Status in OpenStack Compute (nova): Opinion Bug description: Provide the implementation similar to the Amazon EC2 API ec2-reset-snapshot-attribute for making the volume based snapshot instances accessible only to the respective account holder. http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference /ApiReference-cmd-ResetSnapshotAttribute.html To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1398357/+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 1318588] Re: Volume create time format is not as per the AWS create time
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Confirmed ** Changed in: ec2-api Importance: Undecided = Low -- 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/1318588 Title: Volume create time format is not as per the AWS create time Status in ec2-api: Confirmed Status in OpenStack Compute (nova): Opinion Bug description: With openstack, the volume creation time is 'createTime2014-05-12T10:08:22.00/createTime' But with AWS, create volume time shows as :'createTime2014-05-12T10:06:41.885Z/createTime' For microseconds, 3 digits are extra and time zone is missing. This need to be fixed to sync-up with AWS create volume time. Doesn't look like a big issue though, but nevertheless shouldn't happen. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1318588/+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 1398361] Re: Add support for EC2 API : ec2-modify-snapshot-attribute
cinder doesn't allow to modify permissions for snapshots/volumes. These objects can be seen only by owner or admin. ** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Opinion ** Changed in: ec2-api Importance: Undecided = Wishlist -- 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/1398361 Title: Add support for EC2 API : ec2-modify-snapshot-attribute Status in ec2-api: Opinion Status in OpenStack Compute (nova): Opinion Bug description: The various attributes of the snapshots created from volumes can be modified for making them accessible to public or to a particular user account. The response parameters and supported attribute sets must be according the AWS specification: http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-ModifySnapshotAttribute.html To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1398361/+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 836973] Re: nova should keep instance data after termination
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Confirmed ** Changed in: ec2-api Importance: Undecided = Wishlist -- 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/836973 Title: nova should keep instance data after termination Status in ec2-api: Confirmed Status in OpenStack Compute (nova): Opinion Bug description: On EC2, instances are available in DescribeInstances output afer they're terminated. In nova, at the moment, they disappear immediately. This makes getting shutdown console output just about impossible. Relevant link to amazon ec2 documentation: http://docs.amazonwebservices.com/AWSEC2/latest/DeveloperGuide/index.html?instance-console.html Only the most recent 64 KB of posted output is stored, which is available for at least 1 hour after the last posting. $ euca-run-instances --key mykey ami-0056 RESERVATION r-227nsegw smoser_project default INSTANCE i-0200 ami-0056scheduling mykey 0 m1.small2011-08-29T20:11:09Zunknown zone aki-0052ari-0053 $ euca-get-console-output i-0201 | tail -n 5 ec2: 1024 83:c3:7a:9b:42:fc:0d:c5:48:96:bd:46:62:25:bf:34 /etc/ssh/ssh_host_dsa_key.pub (DSA) ec2: -END SSH HOST KEY FINGERPRINTS- ec2: # landscape-client is not configured, please run landscape-config. $ euca-terminate-instances i-0201 #no output # wait 10 seconds or so $ euca-describe-instances i-0201 #no output $ echo $? 0 $ euca-get-console-output i-0201 InstanceNotFound: Instance %(instance_id)s could not be found. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/836973/+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 1278526] Re: EC2 signature verification does not take port into account
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Confirmed ** Changed in: ec2-api Importance: Undecided = Low -- 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/1278526 Title: EC2 signature verification does not take port into account Status in ec2-api: Confirmed Status in OpenStack Compute (nova): Opinion Bug description: Nova Version: master (and probably previous) Tested with euca2ools 3.0.2-1 on Debian Line numbers based on commit 48e8f992f46862cb4f50fe0cc9b77a3017e7bb23 in master for nova, commit 8557e4756e8a326579df826076478d98ca634345 in master for keystone. EC2 protocol requires Signature calculated for every request. The signature is calculated from: access_key, signature, host, verb, path and params. These values together with the signature are passed to Keystone for verification as seen in: https://github.com/openstack/nova/blob/master/nova/api/ec2/__init__.py#L201-L232 Verification is done by Kestone's check_signature functon define: https://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/controllers.py#L53-L67 The root of the problem: - euca2ools use port in host field (hostname.of.endpoint:8773 for signing signature - keystone takes into account that client signing the request may append the port into the host field and does the signature verification twice: with the port and without - nova never passes the port along with the host to keystone (line 205 of nova/api/ec2/__init__.py) This results in always incorrect signature rendering EC2 protocol useless for clients that append port to the host. It is not an issue if the port is not used to calculate signature if such clients exist. Simple fix: append the port in /nova/api/ec2/__init__.py line 204. Actual problem: for deployments that use SSL termination proxy and/or rewrite URLs, the port visible to the client is not necessarily the standard port used by Nova for EC2 (8773) nor the one specified in the configuration for nova to listen on. Therefore, I suggest to create a new configuration option for this purpose, which dynamically defaults to ec2_listen_port (usually 8773). It also seems that ec2_port configuration option can be used for that purpose as it already has this meaning to hold port visible by the user, not the one that EC2 API is listening on. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1278526/+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 829880] Re: object store doesn't like key with '/'
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Fix Committed ** Changed in: ec2-api 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/829880 Title: object store doesn't like key with '/' Status in ec2-api: Fix Committed Status in pyjuju: Fix Released Status in OpenStack Compute (nova): Won't Fix Status in juju package in Ubuntu: Fix Released Bug description: It looks like it should be correct given that its taking a hash of the key for the filename in the bucket dir, but it looks like its running afoul before it gets there.. sample script to reproduce (python+boto) against nova-objectstore (s3server.py) import boto import os from boto.s3.connection import S3Connection, OrdinaryCallingFormat s3 = S3Connection( aws_access_key_id=os.environ[EC2_ACCESS_KEY], aws_secret_access_key=os.environ[EC2_SECRET_KEY], host = os.environ[S3_URL][len(http://;):], is_secure = False, calling_format=OrdinaryCallingFormat()) bucket = s3.create_bucket(es-testing-123) print new key key = bucket.new_key(abc.txt) key.set_contents_from_string(abcdef) print new nested key key = bucket.new_key(zoo/abc.txt) key.set_contents_from_string(abcdef) Fails with S3ResponseError: 404 Not Found 404 Not Found The resource could not be found. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/829880/+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 827569] Re: ec2metadata service does not include 2011-01-01
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Confirmed ** Changed in: ec2-api Importance: Undecided = Wishlist -- 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/827569 Title: ec2metadata service does not include 2011-01-01 Status in ec2-api: Confirmed Status in OpenStack Compute (nova): Opinion Bug description: On EC2: $ wget -q -O - http://169.254.169.254/; echo 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 2011-01-01 latest on Openstack: wget -q -O - http://169.254.169.254/; echo 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 I noticed this when using 'ec2metadata'. I shoudl probably back of the api version for that, or use 'latest'. but it would be nice if 2011-01-01 was present. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/827569/+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 1160850] Re: ec2 (DescribeKeyPairs) does not supports filtering by fingerprint
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Fix Committed ** Changed in: ec2-api Importance: Undecided = Low ** Changed in: ec2-api Status: Fix Committed = 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/1160850 Title: ec2 (DescribeKeyPairs) does not supports filtering by fingerprint Status in ec2-api: Fix Released Status in OpenStack Compute (nova): Opinion Bug description: euca-describe-keypairs --filter fingerprint=c0:40:d9:8b:e2:09:11:2b:59:a8:86:3b:03:87:5d:e5 KEYPAIR testc0:40:d9:8b:e2:09:11:2b:59:a8:86:3b:03:87:5d:e5 KEYPAIR test2 1d:25:e8:42:1a:59:ce:59:6c:b1:2c:76:d6:4b:cd:de The listing shows me all keypairs even if I define a filter. nova version: 9a90f6ccdb88a22ff17b3f48d26378b4fa613ede To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1160850/+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 1480301] [NEW] [Sahara] is_proxy_gateway field remains unchanged after update
Public bug reported: Field is_proxy_gateway of node group template objects doesn't change its value after node group template update. ** Affects: horizon Importance: Undecided Assignee: Andrey Pavlov (apavlov-n) Status: In Progress ** Changed in: horizon Assignee: (unassigned) = Andrey Pavlov (apavlov-n) -- 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/1480301 Title: [Sahara] is_proxy_gateway field remains unchanged after update Status in OpenStack Dashboard (Horizon): In Progress Bug description: Field is_proxy_gateway of node group template objects doesn't change its value after node group template update. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1480301/+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 1212581] Re: ec2 api doesn't respect reclaim_instance_interval from nova.conf
standalone ec2-api project doesn't have such bug because it works through piblic Nova API. ** No longer affects: ec2-api -- 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/1212581 Title: ec2 api doesn't respect reclaim_instance_interval from nova.conf Status in OpenStack Compute (Nova): Confirmed Bug description: When a user, uses the ec2 api to delete an instance the check whether the instance should be soft-deleted isn't done. This logic is current in api/nova/ and not in api/ec2. I expected the ec2 api to have the same behavior. We currently lost user data because of this. Would be nice to have compute/api.y only a contain a single delete function which does the checking whether to soft-delete or not instead of doing it in the api level. Impact: High To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1212581/+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 1215527] Re: DescribeInstanceAttribute userData missing value xml element
** Changed in: ec2-api Status: New = Fix Committed ** Changed in: ec2-api Status: Fix Committed = 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/1215527 Title: DescribeInstanceAttribute userData missing value xml element Status in EC2 API: Fix Released Status in OpenStack Compute (Nova): Confirmed Bug description: The nova ec2 compatibility api sends a response differing from ec2 for simple string value types such as userData and disableApiTermination. They are missing the wrapper value xml element. This does not effect complex responses such as groupSet and blockDeviceMapping To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1215527/+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 1325079] Re: Invalid error message for snapshot creation in EC2 layer
** Changed in: ec2-api
Status: New = 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/1325079
Title:
Invalid error message for snapshot creation in EC2 layer
Status in EC2 API:
Fix Released
Status in OpenStack Compute (Nova):
Confirmed
Bug description:
Volume snapshots in EC2 can be created only for volumes in some
particular statuses. For other statuses creation an error should be
returned. Current EC2 code doesn't check the statuses and pass the
request to Cinder code. When it fails creating it returns its own
native error which is incorrectly reported further by EC2 layer.
Environment: DevStack
Steps to reproduce:
1 Run from script:
vol=$(euca-create-volume -z nova -s 1 --snapshot snap-xxx | awk -F
'{print $2}')
euca-create-snapshot $vol
InvalidInput: Invalid input received: Invalid volume: must be
available
If run tthis agains AWS the error output is
IncorrectState: Volume 'vol-xxx' is not in a state where snapshots are
allowed.
Note. To reproduce the error on AWS i recommend to get a non-empty
snapshot about 10GB and increase the size parameter in euca-create-
volume.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ec2-api/+bug/1325079/+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 885090] Re: EC2 and OS Image APIs use inconsistent IDs
** Changed in: ec2-api Status: New = 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/885090 Title: EC2 and OS Image APIs use inconsistent IDs Status in EC2 API: Invalid Status in OpenStack Compute (Nova): Confirmed Bug description: When retrieving images through the EC2 API, the image id looks like ami-0001; when using the OS API it looks like 1. Sadly the EC2 API only accepts the ami-0001 format, which means that if you query the OS API to get the image (which you have to do to get the metadata) you then can't use that image API to create an instance (which you have to do to specify an SSH key). While I can perform the same mapping that the EC2 API no doubt does under the covers, I really shouldn't have to - I suggest that the EC2 API should be returned in the metadata, or the EC2 API create call should accept an OS Image Id. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/885090/+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 1370339] Re: Cannot register volume backed image by EC2 API
** Changed in: ec2-api Status: New = 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/1370339 Title: Cannot register volume backed image by EC2 API Status in EC2 API: Fix Released Status in OpenStack Compute (Nova): Confirmed Bug description: AWS allows to register a volume backed image. But Nova doesn't: $ euca-register -n ebs-image --kernel aki-0002 --ramdisk ari-0003 --root-device-name /dev/vda -b /dev/vda=snap-0006 euca-register: error (HTTPInternalServerError): The server has either erred or is incapable of performing the requested operation. In fact this feature is not implemented in Nova. But this feature is used in 'Launching an Instance from a Backup' AWS scenario (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-launch- snapshot.html). To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1370339/+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 954335] Re: registering new image from existing s3 location does not respect kernel/ramdisk/name
** Changed in: ec2-api Status: New = 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/954335 Title: registering new image from existing s3 location does not respect kernel/ramdisk/name Status in EC2 API: Fix Released Status in OpenStack Compute (Nova): Confirmed Bug description: $ cloud-publish-image --type kernel --rename my-kernel.img amd64 my.img my-bucket aki-000fmy-bucket/my-kernel.img.manifest.xml $ cloud-publish-image --type ramdisk --rename my-ramdisk.img amd64 my.img my-bucket ari-0010my-bucket/my-ramdisk.img.manifest.xml $ cloud-publish-image --type image --rename my-image-01.img amd64 my.img my-bucket ami-0011my-bucket/my-image-01.img.manifest.xml $ euca-register my-bucket/my-image-01.img.manifest.xml --kernel aki-000f --ramdisk ari-0010 --name my-bucket/my-image-01-with-kenrel-ramdisk.img IMAGE ami-0012 $ euca-describe-images ami-0012 IMAGE ami-0012my-bucket/my-image-01.img.manifest.xml available private x86_64 machine instance-store However, if you pass --kernel/--ramdisk the first time you register that s3 location, then it works. $ cloud-publish-image --type image --rename my-image-02.img amd64 my.img my-bucket --kernel aki-000f --ramdisk ari-0010 ami-0013my-bucket/my-image-02.img.manifest.xml $ euca-describe-images ami-0013 IMAGE ami-0013my-bucket/my-image-02.img.manifest.xml available private x86_64 machine aki-000fari-0010 instance-store The desired behavior is basically to re-register that s3 location but with different kernel/ramdisk (or --name) parameters. Euca-describe-images shows the following: $ euca-describe-images | grep my-bucket/ IMAGE aki-000fmy-bucket/my-kernel.img.manifest.xml available private x86_64 kernel instance-store IMAGE ari-0010my-bucket/my-ramdisk.img.manifest.xml available private x86_64 ramdisk instance-store IMAGE ami-0011my-bucket/my-image-01.img.manifest.xml available private x86_64 machine instance-store IMAGE ami-0012my-bucket/my-image-01.img.manifest.xml available private x86_64 machine instance-store IMAGE ami-0013my-bucket/my-image-02.img.manifest.xml available private x86_64 machine aki-000fari-0010 instance-store $ glance index /dev/null | grep my-bucket 09e381db-4281-4678-9c4b-854158148643 my-bucket/my-image-02.img ami ami10485760 f90dd1a9-301c-4ee9-9636-af1fd2454872 my-bucket/my-image-01-with-ken ami ami10485760 4799f149-0d04-4b5a-bd2a-f0bf96e97a1d my-bucket/my-image-01.img ami ami10485760 909651a3-e3c1-4858-946e-17433ef73aed my-bucket/my-ramdisk.img ari ari10485760 228a64fd-dadc-4cec-9954-92fef2251413 my-bucket/my-kernel.imgaki aki10485760 To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/954335/+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 1272844] Re: Fails to 'modify_image_attribute()' for ec2
** Changed in: ec2-api
Status: New = Fix Committed
** Changed in: ec2-api
Status: Fix Committed = Fix Released
** Changed in: ec2-api
Assignee: (unassigned) = Andrey Pavlov (apavlov-e)
--
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/1272844
Title:
Fails to 'modify_image_attribute()' for ec2
Status in EC2 API:
Fix Released
Status in OpenStack Compute (Nova):
Confirmed
Bug description:
The params of modify_image_attribute() in cloud.py, are not matched
with ec2 api.
-
I checked the ec2 api, the url is like:
https://ec2.amazonaws.com/?Action=ModifyImageAttribute
ImageId=ami-61a54008
LaunchPermission.Remove.1.UserId=
And I tested again with euca2ools, the modify_image_attribute() failed
again:
TypeError: 'modify_image_attribute() takes exactly 5 non-keyword
arguments (3 given)'
--
Here is the definition of modify_image_attribute():
def modify_image_attribute(self, context, image_id, attribute,
operation_type, **kwargs)
And I printed out the params send to here, the value of args is:
args={'launch_permission': {'add': {'1': {'group': u'all'}}}, 'image_id':
u'ami-0004'}
--
So I got a question, are the params used in modify_image_attribute()
correct?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ec2-api/+bug/1272844/+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 1075051] Re: AWS credentials delegation to S3/Swift3
** Changed in: ec2-api Status: New = 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/1075051 Title: AWS credentials delegation to S3/Swift3 Status in EC2 API: Fix Released Status in OpenStack Compute (Nova): Confirmed Bug description: Now (openstack-nova-api-2012.2-1.fc18) , when the nova tries to connect to the S3 storage it tries to use the credentials hard coded to the config file. It means every RegisterImage call will use the same tenant credentials instead of their own tenant credentials. I think nova should delegate authentication to the swift backed, even by using other access method with the original requester permissions/roles. Note1: Probably this behaviour originated the days where the nova-objectstore used and it does not validated credentials. Note2: Part of AWS credential is a signature of the request by the secret key, simple forwarding probably will not work. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1075051/+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 1263993] Re: nova-api ec2 DescribeInstaces returns invalid xml under certain conditions
** Changed in: ec2-api Status: New = 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/1263993 Title: nova-api ec2 DescribeInstaces returns invalid xml under certain conditions Status in EC2 API: Fix Released Status in OpenStack Compute (Nova): Confirmed Bug description: XML returned from nova ec2 api for Action=DescribeInstances is invalid when filtered by an instance with an attached volume. The closing tag of rootDeviceName xml is truncated. No filter returns valid xml (describe all instances) and filtering on specific instance without an attached volume returns valid xml. rootDeviceName/dev/vda/roo rootDeviceType instance-store/rootDeviceType Complete request/response from packet capture: http://paste.openstack.org/show/56741/ python-2.7.3-0ubuntu3.4 nova --version 2.15.0.39 To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1263993/+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 1370250] Re: Can not set volume attributes at instance launch by EC2 API
** Also affects: ec2-api 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/1370250 Title: Can not set volume attributes at instance launch by EC2 API Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: AWS allows to change block device attributes (such as volume size, delete on termination behavior, existence) at instance launch. For example, image xxx has devices: vda, size 10, delete on termination vdb, size 100, delete on termination vdc, size 100, delete on termination We can run an instance by euca-run-instances ... xxx -b /dev/vda=:20 -b /dev/vdb=::false -b /dev/vdc=none to get the instance with devices: vda, size 20, delete on termination vdb, size 100, not delete on termination For Nova we get now: $ euca-run-instances --instance-type m1.nano -b /dev/vda=::true ami-000a euca-run-instances: error (InvalidBDMFormat): Block Device Mapping is Invalid: Unrecognized legacy format. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1370250/+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 1370330] Re: Cannot attach a volume without '/dev/' prefix by EC2 API
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Confirmed -- 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/1370330 Title: Cannot attach a volume without '/dev/' prefix by EC2 API Status in EC2 API: Confirmed Status in OpenStack Compute (Nova): Confirmed Bug description: AWS allows to attach a volume with short device name (without '/dev/' prefix). But Nova doesn't. $ euca-attach-volume -i i-0008 -d vdd vol-0003 euca-attach-volume: error (InvalidDevicePath): The supplied device path (vdd) is invalid. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1370330/+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 1370177] Re: Lack of EC2 image attributes for volume backed snapshot.
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Confirmed -- 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/1370177 Title: Lack of EC2 image attributes for volume backed snapshot. Status in EC2 API: Confirmed Status in OpenStack Compute (Nova): Confirmed Bug description: For EBS images AWS returns device names, volume sizes, delete on termination flags in block device mapping structure. $ euca-describe-images ami-d13845e1 IMAGE ami-d13845e1amazon/amzn-ami-hvm-2014.03.2.x86_64-ebsamazon available public x86_64 machine ebs hvm xen BLOCKDEVICEMAPPING/dev/xvda snap-d15cde24 8 true The same in xml form: blockDeviceMapping item deviceName/dev/xvda/deviceName ebs snapshotIdsnap-d15cde24/snapshotId volumeSize8/volumeSize deleteOnTerminationtrue/deleteOnTermination volumeTypestandard/volumeType /ebs /item /blockDeviceMapping But Nova didn't do it now: $ euca-describe-images ami-000a IMAGE ami-000aNone (sn-in)ef3ddd7aa4b24cda974200baef02730b available private machine aki-0002ari-0003 instance-store BLOCKDEVICEMAPPINGsnap-0005 The same in xml form: blockDeviceMapping item ebs snapshotIdsnap-0005/snapshotId /ebs /item /blockDeviceMapping NB. In Grizzly device names and delete on termination flags was returned. It was changed by https://github.com/openstack/nova/commit/33e3d4c6b9e0b11500fe47d861110be1c1981572 Now these attributes are not stored in instance snapshots, so there is no way to output them. Device name is most critical attribute. Because there is another one compatibility issue (see https://bugs.launchpad.net/nova/+bug/1370250): Nova isn't able to adjust attributes of volume being created at instance launch stage. For example in AWS we can change volume size and delete on termination flag of a device by set new values in parameters of run instance command. To identify the device in image block device mapping we use device name. For example: euca-run-instances ... -b /dev/vda=:100 runs an instance with vda device increased to 100 GB. Thus if we haven't device names in images, we haven't a chance to fix this compatibility problem. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1370177/+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 1371445] Re: Nova EC2 doesn't assign a floating IP to an instance being launched
** Also affects: ec2-api 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/1371445 Title: Nova EC2 doesn't assign a floating IP to an instance being launched Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: In EC2 classic mode AWS automatically associates a public IP address to an instance being launched. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance- addressing.html#differences Since Nova EC2 emulates EC2 classic mode of AWS (there is no VPC support in Nova EC2), it should associate a floating IP as well. But it doesn't do this. Though Nova has auto_assign_floating_ip parameter which does work similar AWS. But it isn't implemented for Neutron networks. And it affects both methods of running: EC2 and native Nova. Thus if we want a cloud to be AWS compatible, and we use this parameter, we change behavior of Nova in it's native part. This may be not desirable. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1371445/+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 1433994] [NEW] Can't boot instance with fake_virt driver in flavor that has disk size 0
Public bug reported: I set VIRT_DRVER=fake for my devstack. And when I try to boot instance with flavor m1.tiny nova scheduler says that I don't have disk space - ram:799488 disk:0 io_ops:0 instances:0 does not have 1024 MB usable disk, it only has 0.0 MB usable disk. It happens because scheduler calculates free_gb as minimum from 'compute.disk_available_least' and 'compute.free_disk_gb' if least is not None but fake_virt driver defines 'disk_available_least = 0'. Maybe this is not a bug about booting instance but maybe a bug about list of flavors for fake_virt driver. (or friendly message that this operation can not be proceeded). ** Affects: nova 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/1433994 Title: Can't boot instance with fake_virt driver in flavor that has disk size 0 Status in OpenStack Compute (Nova): New Bug description: I set VIRT_DRVER=fake for my devstack. And when I try to boot instance with flavor m1.tiny nova scheduler says that I don't have disk space - ram:799488 disk:0 io_ops:0 instances:0 does not have 1024 MB usable disk, it only has 0.0 MB usable disk. It happens because scheduler calculates free_gb as minimum from 'compute.disk_available_least' and 'compute.free_disk_gb' if least is not None but fake_virt driver defines 'disk_available_least = 0'. Maybe this is not a bug about booting instance but maybe a bug about list of flavors for fake_virt driver. (or friendly message that this operation can not be proceeded). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1433994/+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 1433524] [NEW] Nova deletes first preexisting port if second was attached to instance
Public bug reported:
based on this change -
https://github.com/openstack/nova/commit/1153a46738fc398a1df9d94b5a55fdd58777
If I boot instance with preexisting port and delete this instance then port
remains.
But If I boot instance with preexisting port and attach one more port then
first port is deleted while I delete the instance.
1) Create port with neutron
| 81c98edb-06ac-4286-ad7a-2edeb901474b | | fa:16:3e:5b:1d:c6 |
{subnet_id: 71b456c2-4805-4905-a8d8-9293e162f917, ip_address:
172.24.4.4} |
2) Run instance with this port
(0):~/devstack$ nova boot ttt --flavor 42 --image
aab2d892-636d-4bde-8636-71f8ffd3c51d --nic
port-id=81c98edb-06ac-4286-ad7a-2edeb901474b
port list -
~/devstack$ neutron port-list
+--+--+---+---+
| id | name | mac_address | fixed_ips
|
+--+--+---+---+
| 81c98edb-06ac-4286-ad7a-2edeb901474b | | fa:16:3e:5b:1d:c6 |
{subnet_id: 71b456c2-4805-4905-a8d8-9293e162f917, ip_address:
172.24.4.4} |
| a92337de-d3f2-4a5c-beb4-54bd48ec043f | | fa:16:3e:41:b9:00 |
{subnet_id: 134b9bd5-da87-4b8f-880d-72e24206a721, ip_address: 10.0.0.1}
|
| e59d3841-215a-4352-a212-d5cac5cb7bbe | | fa:16:3e:06:4b:27 |
{subnet_id: 134b9bd5-da87-4b8f-880d-72e24206a721, ip_address: 10.0.0.2}
|
| fa67a224-907e-4c11-bcae-9d919330c6b8 | | fa:16:3e:5e:2d:a7 |
{subnet_id: 71b456c2-4805-4905-a8d8-9293e162f917, ip_address:
172.24.4.2} |
+--+--+---+---+
3) Create another port
(0):~/devstack$ neutron port-create public
| fixed_ips | {subnet_id: 71b456c2-4805-4905-a8d8-9293e162f917,
ip_address: 172.24.4.8} |
| id| a26c8bc0-ea94-4abb-9ffc-752a594e08e7
|
4) attach port to the instance
(0):~/devstack$ nova interface-attach --port-id
a26c8bc0-ea94-4abb-9ffc-752a594e08e7 ttt
5) check instance ports -
(0):~/devstack$ nova interface-list ttt
++--+--+--+---+
| Port State | Port ID | Net ID
| IP addresses | MAC Addr |
++--+--+--+---+
| DOWN | 81c98edb-06ac-4286-ad7a-2edeb901474b |
1e629e00-28b6-4a67-9940-dee2660a23a8 | 172.24.4.4 | fa:16:3e:5b:1d:c6 |
| DOWN | a26c8bc0-ea94-4abb-9ffc-752a594e08e7 |
1e629e00-28b6-4a67-9940-dee2660a23a8 | 172.24.4.8 | fa:16:3e:a1:74:eb |
++--+--+--+---+
(0):~/devstack$ neutron port-list
+--+--+---+---+
| id | name | mac_address | fixed_ips
|
+--+--+---+---+
| 81c98edb-06ac-4286-ad7a-2edeb901474b | | fa:16:3e:5b:1d:c6 |
{subnet_id: 71b456c2-4805-4905-a8d8-9293e162f917, ip_address:
172.24.4.4} |
| a26c8bc0-ea94-4abb-9ffc-752a594e08e7 | | fa:16:3e:a1:74:eb |
{subnet_id: 71b456c2-4805-4905-a8d8-9293e162f917, ip_address:
172.24.4.8} |
| a92337de-d3f2-4a5c-beb4-54bd48ec043f | | fa:16:3e:41:b9:00 |
{subnet_id: 134b9bd5-da87-4b8f-880d-72e24206a721, ip_address: 10.0.0.1}
|
| e59d3841-215a-4352-a212-d5cac5cb7bbe | | fa:16:3e:06:4b:27 |
{subnet_id: 134b9bd5-da87-4b8f-880d-72e24206a721, ip_address: 10.0.0.2}
|
| fa67a224-907e-4c11-bcae-9d919330c6b8 | | fa:16:3e:5e:2d:a7 |
{subnet_id: 71b456c2-4805-4905-a8d8-9293e162f917, ip_address:
172.24.4.2} |
+--+--+---+---+
6) delete instance and check ports in neutron -
(0):~/devstack$ neutron port-list
+--+--+---+---+
| id | name | mac_address | fixed_ips
|
[Yahoo-eng-team] [Bug 1370022] Re: Keystone cannot cope with being behind an SSL terminator for version list
** Changed in: keystone
Status: Invalid = New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1370022
Title:
Keystone cannot cope with being behind an SSL terminator for version
list
Status in OpenStack Identity (Keystone):
New
Bug description:
When keystone set up behind SSL termintator then it returns 'http' as
protocol in URLs returned by version list command -
user@host:~$ curl https://MYHOST:5000/
{versions: {values: [{status: stable, updated:
2013-03-06T00:00:00Z, media-types: [{base: application/json,
type: application/vnd.openstack.identity-v3+json}, {base:
application/xml, type:
application/vnd.openstack.identity-v3+xml}], id: v3.0, links:
[{href: http://MYHOST:5000/v3/;, rel: self}]}, {status:
stable, updated: 2014-04-17T00:00:00Z, media-types: [{base:
application/json, type:
application/vnd.openstack.identity-v2.0+json}, {base:
application/xml, type:
application/vnd.openstack.identity-v2.0+xml}], id: v2.0,
links: [{href: http://MYHOST:5000/v2.0/;, rel: self},
{href: http://docs.openstack.org/api/openstack-identity-
service/2.0/content/, type: text/html, rel: describedby},
{href: http://docs.openstack.org/api/openstack-identity-service/2.0
/identity-dev-guide-2.0.pdf, type: application/pdf, rel:
describedby}]}]}}
my ha_proxyconfig -
frontend keystone_main_frontend
bind 172.31.7.253:5000
bind 172.31.7.252:5000 ssl crt /etc/haproxy/certs/runtime
reqadd X-Forwarded-Proto:\ https if { ssl_fc }
default_backend keystone_main_backend
option httpclose
option http-pretend-keepalive
option forwardfor
backend keystone_main_backend
server HOST1 172.31.0.10:5000 check
server HOST2 172.31.0.12:5000 check
server HOST3 172.31.0.16:5000 check
Similar bug is here https://bugs.launchpad.net/heat/+bug/123
And because of this bug last cinder client doesn't work -
user@host:~$cinder --os-username admin --os-tenant-name admin --os-password
password --os-auth-url https://MYHOST:5000/v2.0/ --endpoint-type publicURL
--debug list
ERROR: Unable to establish connection to http://MYHOST:5000/v2.0/tokens
Also - if I set public_endpoint and admin_endpoint in keystone.conf to use
'https' proto then all works.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1370022/+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 1370022] [NEW] Keystone cannot cope with being behind an SSL terminator for version list
Public bug reported:
When keystone set up behind SSL termintator then it returns 'http' as
protocol in URLs returned by version list command -
user@host:~$ curl https://MYHOST:5000/
{versions: {values: [{status: stable, updated:
2013-03-06T00:00:00Z, media-types: [{base: application/json,
type: application/vnd.openstack.identity-v3+json}, {base:
application/xml, type:
application/vnd.openstack.identity-v3+xml}], id: v3.0, links:
[{href: http://MYHOST:5000/v3/;, rel: self}]}, {status:
stable, updated: 2014-04-17T00:00:00Z, media-types: [{base:
application/json, type:
application/vnd.openstack.identity-v2.0+json}, {base:
application/xml, type:
application/vnd.openstack.identity-v2.0+xml}], id: v2.0, links:
[{href: http://MYHOST:5000/v2.0/;, rel: self}, {href:
http://docs.openstack.org/api/openstack-identity-service/2.0/content/;,
type: text/html, rel: describedby}, {href:
http://docs.openstack.org/api/openstack-identity-service/2.0/identity-
dev-guide-2.0.pdf, type: application/pdf, rel:
describedby}]}]}}
my ha_proxyconfig -
frontend keystone_main_frontend
bind 172.31.7.253:5000
bind 172.31.7.252:5000 ssl crt /etc/haproxy/certs/runtime
reqadd X-Forwarded-Proto:\ https if { ssl_fc }
default_backend keystone_main_backend
option httpclose
option http-pretend-keepalive
option forwardfor
backend keystone_main_backend
server HOST1 172.31.0.10:5000 check
server HOST2 172.31.0.12:5000 check
server HOST3 172.31.0.16:5000 check
Similar bug is here https://bugs.launchpad.net/heat/+bug/123
And because of this bug last cinder client doesn't work -
user@host:~$cinder --os-username admin --os-tenant-name admin --os-password
password --os-auth-url https://MYHOST:5000/v2.0/ --endpoint-type publicURL
--debug list
ERROR: Unable to establish connection to http://MYHOST:5000/v2.0/tokens
Also - if I set public_endpoint and admin_endpoint in keystone.conf to use
'https' proto then all works.
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1370022
Title:
Keystone cannot cope with being behind an SSL terminator for version
list
Status in OpenStack Identity (Keystone):
New
Bug description:
When keystone set up behind SSL termintator then it returns 'http' as
protocol in URLs returned by version list command -
user@host:~$ curl https://MYHOST:5000/
{versions: {values: [{status: stable, updated:
2013-03-06T00:00:00Z, media-types: [{base: application/json,
type: application/vnd.openstack.identity-v3+json}, {base:
application/xml, type:
application/vnd.openstack.identity-v3+xml}], id: v3.0, links:
[{href: http://MYHOST:5000/v3/;, rel: self}]}, {status:
stable, updated: 2014-04-17T00:00:00Z, media-types: [{base:
application/json, type:
application/vnd.openstack.identity-v2.0+json}, {base:
application/xml, type:
application/vnd.openstack.identity-v2.0+xml}], id: v2.0,
links: [{href: http://MYHOST:5000/v2.0/;, rel: self},
{href: http://docs.openstack.org/api/openstack-identity-
service/2.0/content/, type: text/html, rel: describedby},
{href: http://docs.openstack.org/api/openstack-identity-service/2.0
/identity-dev-guide-2.0.pdf, type: application/pdf, rel:
describedby}]}]}}
my ha_proxyconfig -
frontend keystone_main_frontend
bind 172.31.7.253:5000
bind 172.31.7.252:5000 ssl crt /etc/haproxy/certs/runtime
reqadd X-Forwarded-Proto:\ https if { ssl_fc }
default_backend keystone_main_backend
option httpclose
option http-pretend-keepalive
option forwardfor
backend keystone_main_backend
server HOST1 172.31.0.10:5000 check
server HOST2 172.31.0.12:5000 check
server HOST3 172.31.0.16:5000 check
Similar bug is here https://bugs.launchpad.net/heat/+bug/123
And because of this bug last cinder client doesn't work -
user@host:~$cinder --os-username admin --os-tenant-name admin --os-password
password --os-auth-url https://MYHOST:5000/v2.0/ --endpoint-type publicURL
--debug list
ERROR: Unable to establish connection to http://MYHOST:5000/v2.0/tokens
Also - if I set public_endpoint and admin_endpoint in keystone.conf to use
'https' proto then all works.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1370022/+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
