From reza.b2008 at gmail.com  Mon Oct  1 06:54:48 2018
From: reza.b2008 at gmail.com (Reza Bakhshayeshi)
Date: Mon, 1 Oct 2018 10:24:48 +0330
Subject: [Openstack] OpenStack Liberty: unable to create snapshot
	EndpointNotFound/unauthorized
In-Reply-To: <d16060c2-7141-9c61-6ed3-0466e88da471@gmail.com>
References: <d16060c2-7141-9c61-6ed3-0466e88da471@gmail.com>
Message-ID: <CAMGoRG1PJC191S4AaE1iDcQ=_kJr4NViwDhmxH4=7NKXdp+bNQ@mail.gmail.com>

Hi

Still I've the same problem (in newton)
Is there any workaround for this issue?

Regards,
Reza

On Sat, 9 Apr 2016 at 23:22, freelance455 at gmail.com <freelance455 at gmail.com>
wrote:

> Hi!
>
> I'm trying to create a snapshot with:
>
> # cinder snapshot-create --force --name snap01
> f0b8a7c2-6112-4e59-a037-97502b081141
>
> and get 'Call to Nova to create snapshot failed EndpointNotFound' error
> in log:
>
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs
> [req-71115c09-449e-4052-a7ad-e7836811b8b0 openstack-admin
> 0b814f7b33ad4d5697a0d1b8cd28251f - - -] Call to Nova to create snapshot
> failed
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs Traceback
> (most recent call last):
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/cinder/volume/drivers/remotefs.py",
> line 1277, in _create_snapshot_online
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs connection_info)
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/cinder/compute/nova.py", line 178, in
> create_volume_snapshot
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs nova =
> novaclient(context, admin_endpoint=True, privileged_user=True)
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/cinder/compute/nova.py", line 137, in
> novaclient
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs **region_filter)
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/novaclient/service_catalog.py", line
> 84, in url_for
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs raise
> novaclient.exceptions.EndpointNotFound()
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs EndpointNotFound
> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs
>
> If I change
>
> nova_catalog_info = compute:Compute Service:publicURL
>
> to
>
> nova_catalog_admin_info = compute:nova:adminURL
>
> and
>
> nova_catalog_admin_info = compute:Compute Service:adminURL
>
> to
>
> nova_catalog_admin_info = compute:nova:adminURL
>
> in /etc/cinder/cinder.conf , I get a different error message "Call to
> Nova to create snapshot failed - Unauthorized: Unauthorized (HTTP 401)":
>
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs
> [req-edd7717f-2d64-4f16-b38e-981597eb466a openstack-admin
> 0b814f7b33ad4d5697a0d1b8cd28251f - - -] Call to Nova to create snapshot
> failed
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs Traceback
> (most recent call last):
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/cinder/volume/drivers/remotefs.py",
> line 1277, in _create_snapshot_online
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs connection_info)
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/cinder/compute/nova.py", line 183, in
> create_volume_snapshot
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs
> create_info=create_info)
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/novaclient/v2/contrib/assisted_volume_snapshots.py",
>
> line 41, in create
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs return
> self._create('/os-assisted-volume-snapshots', body, 'snapshot')
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/novaclient/base.py", line 169, in _create
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs _resp, body =
> self.api.client.post(url, body=body)
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 449, in post
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs return
> self._cs_request(url, 'POST', **kwargs)
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 402, in
> _cs_request
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs
> self.authenticate()
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 574, in
> authenticate
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs auth_url =
> self._v1_auth(auth_url)
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 610, in
> _v1_auth
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs resp, body =
> self._time_request(url, 'GET', headers=headers)
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 397, in
> _time_request
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs resp, body =
> self.request(url, method, **kwargs)
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 391, in
> request
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs raise
> exceptions.from_response(resp, body, url, method)
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs Unauthorized:
> Unauthorized (HTTP 401) (Request-ID:
> req-b4f4f1cf-cd1f-4ef2-831d-baa531acf980)
> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs
> cinder-volume[23456]: ERROR oslo_messaging.rpc.dispatcher
> [req-edd7717f-2d64-4f16-b38e-981597eb466a openstack-admin
> 0b814f7b33ad4d5697a0d1b8cd28251f - - -] Exception during message
> handling: (Unauthorized(),)
>
> And the following message in nova-api.log:
>
> INFO nova.osapi_compute.wsgi.server [-] 11.22.33.44 "GET
> /v2/0b814f7b33ad4d5697a0d1b8cd28251f HTTP/1.1" status: 401 len: 302
> time: 0.0006430
>
> All the other cinder and nova commands work without any problems. This
> only happens when I try to create a snapshot.
>
> # openstack catalog list
>
> | nova       | compute      | RegionOne |
> |            |              |   publicURL:
> http://11.22.33.44:8774/v2/0b814f7b33ad4d5697a0d1b8cd28251f |
> |            |              |   internalURL:
> http://11.22.33.44:8774/v2/0b814f7b33ad4d5697a0d1b8cd28251f      |
> |            |              |   adminURL:
> http://11.22.33.44:8774/v2/0b814f7b33ad4d5697a0d1b8cd28251f |
> |            | | |
>
> Nova: 12.0.1
> Cinder: 7.0.1
> OS: Centos 7
>
> I would be very grateful for any help.
>
> Thank you!
>
> Best regards,
> Dmitry
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181001/ea9abe76/attachment.html>

From ken at jots.org  Mon Oct  1 15:32:16 2018
From: ken at jots.org (Ken D'Ambrosio)
Date: Mon, 01 Oct 2018 11:32:16 -0400
Subject: [Openstack] Installing EOL Devstack versions?
Message-ID: <3321632fbcdadd2db79e8b71335d13cd@jots.org>

Hi, all.  We're running an old version of Openstack -- Juno -- and I'd 
like to test some things out before trying to implement them, probably 
in Devstack.  And I could *swear* there was a way to deploy end-of-lifed 
versions of Devstack, but darned if I can find it.

Suggestions?

Thanks kindly,

-Ken


From amy at demarco.com  Mon Oct  1 16:05:56 2018
From: amy at demarco.com (Amy Marrich)
Date: Mon, 1 Oct 2018 11:05:56 -0500
Subject: [Openstack] Installing EOL Devstack versions?
In-Reply-To: <3321632fbcdadd2db79e8b71335d13cd@jots.org>
References: <3321632fbcdadd2db79e8b71335d13cd@jots.org>
Message-ID: <CAFs83QrBS6VbhW0Y2svWqkAyY4Q50MpBY-TH4iDOz=uf_4LEsQ@mail.gmail.com>

Ken,

You can get it here:

https://github.com/openstack-dev/devstack/tree/juno-eol

The secret is to checkout the juno-eol tag vs master or stable/<branch>

Hope that helps!

Amy (spotz)

On Mon, Oct 1, 2018 at 10:32 AM, Ken D'Ambrosio <ken at jots.org> wrote:

> Hi, all.  We're running an old version of Openstack -- Juno -- and I'd
> like to test some things out before trying to implement them, probably in
> Devstack.  And I could *swear* there was a way to deploy end-of-lifed
> versions of Devstack, but darned if I can find it.
>
> Suggestions?
>
> Thanks kindly,
>
> -Ken
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181001/48059ed9/attachment.html>

From kennelson11 at gmail.com  Mon Oct  1 23:57:30 2018
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Mon, 1 Oct 2018 16:57:30 -0700
Subject: [Openstack] Berlin Community Contributor Awards
In-Reply-To: <CAJ6yrQgAgYPobNwZiTSTLDJQEcoMWo1C8ERg3mx36ZMWgqhb4Q@mail.gmail.com>
References: <CAJ6yrQgAgYPobNwZiTSTLDJQEcoMWo1C8ERg3mx36ZMWgqhb4Q@mail.gmail.com>
Message-ID: <CAJ6yrQiKzhk4qZi1RoRhb8Ff2BzOgFz6c9yxRLpX5Odqyuyepw@mail.gmail.com>

Hello :)

I wanted to bring this to the top of people's inboxes as we have three
weeks left to submit community members[1].

I can think of a dozen people right now that deserve an award and I am sure
you all could do the same. It only takes a few minutes and its an easy way
to make sure they get the recognition they deserve. Show your appreciation
and nominate one person.

-Kendall (diablo_rojo)

[1] https://openstackfoundation.formstack.com/forms/berlin_stein_ccas

On Fri, Aug 24, 2018 at 11:15 AM Kendall Nelson <kennelson11 at gmail.com>
wrote:

> Hello Everyone!
>
> As we approach the Summit (still a ways away thankfully), I thought I
> would kick off the Community Contributor Award nominations early this
> round.
>
> For those of you that already know what they are, here is the form[1].
>
> For those of you that have never heard of the CCA, I'll briefly explain
> what they are :) We all know people in the community that do the dirty
> jobs, we all know people that will bend over backwards trying to help
> someone new, we all know someone that is a savant in some area of the code
> we could never hope to understand. These people rarely get the thanks they
> deserve and the Community Contributor Awards are a chance to make sure they
> know that they are appreciated for the amazing work they do and skills they
> have.
>
> So go forth and nominate these amazing community members[1]! Nominations
> will close on October 21st at 7:00 UTC and winners will be announced at the
> OpenStack Summit in Berlin.
>
> -Kendall (diablo_rojo)
>
> [1] https://openstackfoundation.formstack.com/forms/berlin_stein_ccas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181001/66836372/attachment.html>

From reza.b2008 at gmail.com  Tue Oct  2 06:23:03 2018
From: reza.b2008 at gmail.com (Reza Bakhshayeshi)
Date: Tue, 2 Oct 2018 09:53:03 +0330
Subject: [Openstack] OpenStack Liberty: unable to create snapshot
	EndpointNotFound/unauthorized
In-Reply-To: <CAMGoRG1PJC191S4AaE1iDcQ=_kJr4NViwDhmxH4=7NKXdp+bNQ@mail.gmail.com>
References: <d16060c2-7141-9c61-6ed3-0466e88da471@gmail.com>
 <CAMGoRG1PJC191S4AaE1iDcQ=_kJr4NViwDhmxH4=7NKXdp+bNQ@mail.gmail.com>
Message-ID: <CAMGoRG2gvb13kZEBOOapvJM9cRb79RAK7zTiQgZBY07mc=Xj0g@mail.gmail.com>

 My problem solved by adding these lines to cinder.conf

nova_catalog_info = compute:nova:publicURL
nova_catalog_admin_info = compute:nova:adminURL
os_privileged_user_auth_url = http://<controller>:35357
os_privileged_user_name = cinder
os_privileged_user_password = <password>
os_privileged_user_tenant = service

On Mon, 1 Oct 2018 at 10:24, Reza Bakhshayeshi <reza.b2008 at gmail.com> wrote:

> Hi
>
> Still I've the same problem (in newton)
> Is there any workaround for this issue?
>
> Regards,
> Reza
>
> On Sat, 9 Apr 2016 at 23:22, freelance455 at gmail.com <
> freelance455 at gmail.com> wrote:
>
>> Hi!
>>
>> I'm trying to create a snapshot with:
>>
>> # cinder snapshot-create --force --name snap01
>> f0b8a7c2-6112-4e59-a037-97502b081141
>>
>> and get 'Call to Nova to create snapshot failed EndpointNotFound' error
>> in log:
>>
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs
>> [req-71115c09-449e-4052-a7ad-e7836811b8b0 openstack-admin
>> 0b814f7b33ad4d5697a0d1b8cd28251f - - -] Call to Nova to create snapshot
>> failed
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs Traceback
>> (most recent call last):
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/cinder/volume/drivers/remotefs.py",
>> line 1277, in _create_snapshot_online
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs
>> connection_info)
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/cinder/compute/nova.py", line 178, in
>> create_volume_snapshot
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs nova =
>> novaclient(context, admin_endpoint=True, privileged_user=True)
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/cinder/compute/nova.py", line 137, in
>> novaclient
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs
>> **region_filter)
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/novaclient/service_catalog.py", line
>> 84, in url_for
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs raise
>> novaclient.exceptions.EndpointNotFound()
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs
>> EndpointNotFound
>> cinder-volume[20267]: ERROR cinder.volume.drivers.remotefs
>>
>> If I change
>>
>> nova_catalog_info = compute:Compute Service:publicURL
>>
>> to
>>
>> nova_catalog_admin_info = compute:nova:adminURL
>>
>> and
>>
>> nova_catalog_admin_info = compute:Compute Service:adminURL
>>
>> to
>>
>> nova_catalog_admin_info = compute:nova:adminURL
>>
>> in /etc/cinder/cinder.conf , I get a different error message "Call to
>> Nova to create snapshot failed - Unauthorized: Unauthorized (HTTP 401)":
>>
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs
>> [req-edd7717f-2d64-4f16-b38e-981597eb466a openstack-admin
>> 0b814f7b33ad4d5697a0d1b8cd28251f - - -] Call to Nova to create snapshot
>> failed
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs Traceback
>> (most recent call last):
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/cinder/volume/drivers/remotefs.py",
>> line 1277, in _create_snapshot_online
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs
>> connection_info)
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/cinder/compute/nova.py", line 183, in
>> create_volume_snapshot
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs
>> create_info=create_info)
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/novaclient/v2/contrib/assisted_volume_snapshots.py",
>>
>> line 41, in create
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs return
>> self._create('/os-assisted-volume-snapshots', body, 'snapshot')
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/novaclient/base.py", line 169, in
>> _create
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs _resp, body =
>> self.api.client.post(url, body=body)
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 449, in post
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs return
>> self._cs_request(url, 'POST', **kwargs)
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 402, in
>> _cs_request
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs
>> self.authenticate()
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 574, in
>> authenticate
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs auth_url =
>> self._v1_auth(auth_url)
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 610, in
>> _v1_auth
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs resp, body =
>> self._time_request(url, 'GET', headers=headers)
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 397, in
>> _time_request
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs resp, body =
>> self.request(url, method, **kwargs)
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs   File
>> "/usr/lib/python2.7/site-packages/novaclient/client.py", line 391, in
>> request
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs raise
>> exceptions.from_response(resp, body, url, method)
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs Unauthorized:
>> Unauthorized (HTTP 401) (Request-ID:
>> req-b4f4f1cf-cd1f-4ef2-831d-baa531acf980)
>> cinder-volume[23456]: ERROR cinder.volume.drivers.remotefs
>> cinder-volume[23456]: ERROR oslo_messaging.rpc.dispatcher
>> [req-edd7717f-2d64-4f16-b38e-981597eb466a openstack-admin
>> 0b814f7b33ad4d5697a0d1b8cd28251f - - -] Exception during message
>> handling: (Unauthorized(),)
>>
>> And the following message in nova-api.log:
>>
>> INFO nova.osapi_compute.wsgi.server [-] 11.22.33.44 "GET
>> /v2/0b814f7b33ad4d5697a0d1b8cd28251f HTTP/1.1" status: 401 len: 302
>> time: 0.0006430
>>
>> All the other cinder and nova commands work without any problems. This
>> only happens when I try to create a snapshot.
>>
>> # openstack catalog list
>>
>> | nova       | compute      | RegionOne |
>> |            |              |   publicURL:
>> http://11.22.33.44:8774/v2/0b814f7b33ad4d5697a0d1b8cd28251f |
>> |            |              |   internalURL:
>> http://11.22.33.44:8774/v2/0b814f7b33ad4d5697a0d1b8cd28251f      |
>> |            |              |   adminURL:
>> http://11.22.33.44:8774/v2/0b814f7b33ad4d5697a0d1b8cd28251f |
>> |            | | |
>>
>> Nova: 12.0.1
>> Cinder: 7.0.1
>> OS: Centos 7
>>
>> I would be very grateful for any help.
>>
>> Thank you!
>>
>> Best regards,
>> Dmitry
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181002/fc20ecc6/attachment.html>

From tsuyuzaki.kota at lab.ntt.co.jp  Tue Oct  2 06:27:46 2018
From: tsuyuzaki.kota at lab.ntt.co.jp (Kota TSUYUZAKI)
Date: Tue, 02 Oct 2018 15:27:46 +0900
Subject: [Openstack] Can any user add or delete OpenStack Swift
	middleware?
In-Reply-To: <CAMsw+pc0gTJjk4_mbd8ZinBGH9NzbiZ+HujdKr7vDHdviL2AWg@mail.gmail.com>
References: <CAMsw+pdWMWJ0wDE4zeB_sxL0XVw=p=c6dQ4jw4d5O7Xtwdv_pg@mail.gmail.com>
 <EE3014E6-7106-4770-B97C-59CD0ED60A6B@not.mn>
 <5BA05DDE.5060606@lab.ntt.co.jp>
 <CAMsw+pdZS_PdyfLBYmVMqSdkFY8TX55Jve+hDVh3XvK1eFatQQ@mail.gmail.com>
 <5BA08242.9090305@lab.ntt.co.jp>
 <CAMsw+pfdp3KURvh9tKBgVkRG=NwKJsJqn_G16vT2P1nC0tcd6w@mail.gmail.com>
 <5BA4A4F3.8070702@lab.ntt.co.jp>
 <CAMsw+pc0gTJjk4_mbd8ZinBGH9NzbiZ+HujdKr7vDHdviL2AWg@mail.gmail.com>
Message-ID: <5BB30FE2.2030809@lab.ntt.co.jp>

Hi Quao,

See inline responses below, please.

(2018/09/27 0:58), Qiao Kang wrote:
> Kota,
> 
> Sorry for the late response, see more below:
> 
> On Fri, Sep 21, 2018 at 2:59 AM Kota TSUYUZAKI
> <tsuyuzaki.kota at lab.ntt.co.jp> wrote:
>>
>> Hi Qiao,
>>
>>> Thanks! I'm interested and would like to join, as well as contribute!
>>>
>>
>> One example, that is how the multi-READ works, is around [1], the storlets middleware can make a subrequest against to the backend Swift then,
>> attach the request input to the application in the Docker container by passing the file descriptor to be readable[2][3][4]*.
>> After all of the prepartion for the invocation, the input descriptors will be readable in the storlet app as the InputFile.
>>
>> * At first, the runtime prepares the extra source stub at [2], then creates a set of pipes for each sources to be communicated with the app
>> inside the docker daemon[3], then, the runtime module reads the extra data from Swift GET and flushes all buffers into the descriptor [4].
>>
>> 1: https://github.com/openstack/storlets/blob/master/storlets/swift_middleware/handlers/proxy.py#L294-L305
>> 2: https://github.com/openstack/storlets/blob/master/storlets/gateway/gateways/docker/runtime.py#L571-L581
>> 3: https://github.com/openstack/storlets/blob/master/storlets/gateway/gateways/docker/runtime.py#L665-L666
>> 4: https://github.com/openstack/storlets/blob/master/storlets/gateway/gateways/docker/runtime.py#L833-L840
>>
>> Following the mechanism, IMO, what we can do to enable multi-out is
>>
>> - add the capability to create some PUT subrequest at swift_middleware module (define the new API header too)
>> - create the extra communication write-able fds in the storlets runtime (perhaps, storlets daemon is also needed to be changed)
>> - pass all data from the write-able fds as to the sub PUT request input
>>
>>
>> If you have any nice idea rather than me, it's always welcome tho :)
> 
> I think your approach is clear and straightforward. One quick question:
>> - create the extra communication write-able fds in the storlets runtime (perhaps, storlets daemon is also needed to be changed)
> So the Storlet app will write to those fds? Are these fds temporary
> and need to be destroyed after PUT requests in step 3?

Good Question! I don't think we need new code to destory the descriptors.
Note that we have a couple of file descriptors that should be closed successfuly.

One is inside the container, that will be closed [1] at the storlet daemon agent that invoke the storlet app.
The other is the descripter to be read from at the swift middleware layer. That will be passed to a StorletResponse
object, then the reponse object can be closed by wsgi middleware[2][3]. Basically wsgi middleware
has the reponsibility to close the application response iterator so we expect the iterator will be closed around wsgi middleware
pipeline then it propergates to the read fd.

If you find any fd leak that is not intentioned, please feel free to report it as a bug, we had already fought to the leaking descriptors :)

1: https://github.com/openstack/storlets/blob/master/storlets/agent/daemon/server.py#L211-L212
2: https://github.com/openstack/storlets/blob/master/storlets/gateway/gateways/docker/runtime.py#L845
3: https://github.com/openstack/storlets/blob/master/storlets/gateway/common/stob.py#L119-L123


> 
>>
>>> Another potential use case: imagine I want to compress objects upon
>>> PUTs using two different algorithms X and Y, and use the future
>>> 'multi-write' feature to store three objects upon any single PUT
>>> (original copy, X-compressed copy and Y-compressed copy). I can
>>> install two Storlets which implement X and Y respectively. However,
>>> seems Storlets engine can only invoke one per PUT, so this is still
>>> not feasible. Is that correct?
>>>
>>
>> It sounds interesting. As you know, yes, one Storlet application can be invoked per one PUT.
>> On the other hand, Storlets has been capable to run several applications as you want.
>> One idea using the capability, if you develop an application like:
>>
>> - Storlet app invokes several multi threads with their output descriptor
>> - Storlet app reads the input stream, then pushes the data into the threads
>> - Each thread performs as you want (one does as X compression, the other does as Y compression)
>>   then, writes its own result to the output descriptor
>>
>> It might work for your use case.
> 
> Sounds great, I guess it should work as well.
> 
> I'm also concerned with "performance isolation" in Storlets. For
> instance, is it possible for a user to launch several very
> heavy-loaded Storlets apps to consume lots of CPU/memory resources to
> affect other users? Does Storlets do performance/resource isolation?
> 
Currently, we don't have the option to limit such resources but a good news, the storlets apps
will run in docker container so that it has the capability to limit the resouce via cgroups.

Current implementation for the docker command to make the sandbox is around [4] so I guess, expand the args,
then adding configuration to set the resource limitation might work.

4: https://github.com/openstack/storlets/blob/master/scripts/restart_docker_container.c#L68


Thanks,
Kota

> Thanks,
> Qiao
> 
>>
>> Thanks,
>> Kota
>>
>>
>> (2018/09/19 5:52), Qiao Kang wrote:
>>> Dear Kota,
>>>
>>> On Mon, Sep 17, 2018 at 11:43 PM Kota TSUYUZAKI
>>> <tsuyuzaki.kota at lab.ntt.co.jp> wrote:
>>>>
>>>> Hi Quio,
>>>>
>>>>> I know Storlets can provide user-defined computation functionalities,
>>>>> but I guess some capabilities can only be achieved using middleware.
>>>>> For example, a user may want such a feature: upon each PUT request, it
>>>>> creates a compressed copy of the object and stores both the original
>>>>> copy and compressed copy. It's feasible using middlware but I don't
>>>>> think Storlets provide such capability.
>>>>
>>>> Interesting, exactly currently it's not supported to write to multi objects for a PUT request but as well as other middlewares we could adopt the feasibility into Storlets if you prefer.
>>>> Right now, the multi read (i.e. GET from multi sources) is only available and I think we would be able to expand the logic to PUT requests too. IIRC, in those days, we had discussion on sort of the
>>>> multi-out use cases and I'm sure the data structure inside Storlets are designed to be capable to that expantion. At that time, we called them "Tee" application on Storlets, I could not find the
>>>> historical discussion logs about how to implement tho, sorry. I believe that would be an use case for storlets if you prefer the user-defined application flexibilities rather than operator defined
>>>> Swift middleware.
>>>>
>>>> The example of multi-read (GET from multi sources) are here:
>>>> https://github.com/openstack/storlets/blob/master/tests/functional/python/test_multiinput_storlet.py
>>>>
>>>> And if you like to try to write multi write, please join us, I'm happy to help you anytime.
>>>>
>>>
>>> Thanks! I'm interested and would like to join, as well as contribute!
>>>
>>> Another potential use case: imagine I want to compress objects upon
>>> PUTs using two different algorithms X and Y, and use the future
>>> 'multi-write' feature to store three objects upon any single PUT
>>> (original copy, X-compressed copy and Y-compressed copy). I can
>>> install two Storlets which implement X and Y respectively. However,
>>> seems Storlets engine can only invoke one per PUT, so this is still
>>> not feasible. Is that correct?
>>>
>>>>
>>>>> Another example is that a user may want to install a Swift3-like
>>>>> middleware to provide APIs to a 3rd party, but she doesn't want other
>>>>> users to see this middleware.
>>>>>
>>>>
>>>> If the definition can be made by operators, perhaps one possible solution that preparing different proxy-server endpoint for different users is available. i.e. an user uses no-s3api available proxy,
>>>> then the others use a different proxy-server endpoint that has the s3api in the pipeline.
>>>>
>>>> Or, it sounds like kinda defaulter middleware[1], I don't think it has the scope turning on/off the middlewares for now.
>>>>
>>>> 1: https://review.openstack.org/#/c/342857/
>>>
>>> I see, thanks for pointing out the defaulter project!
>>>
>>> Best,
>>> Qiao
>>>
>>>>
>>>> Best,
>>>> Kota
>>>>
>>>> (2018/09/18 11:34), Qiao Kang wrote:
>>>>> Kota,
>>>>>
>>>>> Thanks for your reply, very helpful!
>>>>>
>>>>> I know Storlets can provide user-defined computation functionalities,
>>>>> but I guess some capabilities can only be achieved using middleware.
>>>>> For example, a user may want such a feature: upon each PUT request, it
>>>>> creates a compressed copy of the object and stores both the original
>>>>> copy and compressed copy. It's feasible using middlware but I don't
>>>>> think Storlets provide such capability.
>>>>>
>>>>> Another example is that a user may want to install a Swift3-like
>>>>> middleware to provide APIs to a 3rd party, but she doesn't want other
>>>>> users to see this middleware.
>>>>>
>>>>> Regards,
>>>>> Qiao
>>>>>
>>>>> On Mon, Sep 17, 2018 at 9:19 PM Kota TSUYUZAKI
>>>>> <tsuyuzaki.kota at lab.ntt.co.jp> wrote:
>>>>>>
>>>>>> With Storlets, users will be able to create their own applications that are able to run like as a Swift middeleware. The application (currently Python and Java are supported as the language but the
>>>>>> apps can calls any binaries in the workspace) can be uploaded as a Swift object, then, users can invoke them with just an extra header that specifies your apps.
>>>>>>
>>>>>> To fit your own use case, we may have to consider to invole or to integrate the system for you but I believe Storlets could be a choice for you.
>>>>>>
>>>>>> In detail, Storlets documantation is around there,
>>>>>>
>>>>>> Top Level Index: https://docs.openstack.org/storlets/latest/index.html
>>>>>> System Overview: https://docs.openstack.org/storlets/latest/storlet_engine_overview.html
>>>>>> APIs: https://docs.openstack.org/storlets/latest/api/overview_api.html
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Kota
>>>>>>
>>>>>> (2018/09/17 8:59), John Dickinson wrote:
>>>>>>> You may be interested in Storlets. It's another OpenStack project, maintained by a Swift core reviewer, that provides this sort of user-defined middleware functionality.
>>>>>>>
>>>>>>> You can also ask about it in #openstack-swift
>>>>>>>
>>>>>>> --John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 16 Sep 2018, at 9:25, Qiao Kang wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm wondering whether Swift allows any user (not the administrator) to
>>>>>>>> specify which middleware that she/he wants his data object to go throught.
>>>>>>>> For instance, Alice wants to install a middleware but doesn't want Bob to
>>>>>>>> use it, where Alice and Bob are two accounts in a single Swift cluster.
>>>>>>>>
>>>>>>>> Or maybe all middlewares are pre-installed globally and cannot be
>>>>>>>> customized on a per-account basis?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Qiao
>>>>>>>> _______________________________________________
>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>>>> Post to     : openstack at lists.openstack.org
>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>>> Post to     : openstack at lists.openstack.org
>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ----------------------------------------------------------
>>>>>> Kota Tsuyuzaki(露﨑　浩太)  <tsuyuzaki.kota at lab.ntt.co.jp>
>>>>>> NTT Software Innovation Center
>>>>>> Distributed Computing Technology Project
>>>>>> Phone  0422-59-2837
>>>>>> Fax    0422-59-2965
>>>>>> -----------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>> Post to     : openstack at lists.openstack.org
>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ----------------------------------------------------------
>>>> Kota Tsuyuzaki(露﨑　浩太)  <tsuyuzaki.kota at lab.ntt.co.jp>
>>>> NTT Software Innovation Center
>>>> Distributed Computing Technology Project
>>>> Phone  0422-59-2837
>>>> Fax    0422-59-2965
>>>> -----------------------------------------------------------
>>>>
>>>
>>>
>>
>>
>>
> 
> 


-- 
----------------------------------------------------------
Kota Tsuyuzaki(露﨑　浩太)  <tsuyuzaki.kota at lab.ntt.co.jp>
NTT Software Innovation Center
Distributed Computing Technology Project
Phone  0422-59-2837
Fax    0422-59-2965
-----------------------------------------------------------



From satish.txt at gmail.com  Wed Oct  3 02:07:36 2018
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 2 Oct 2018 22:07:36 -0400
Subject: [Openstack] numa+sriov issue
Message-ID: <CAPgF-frnRjTX3PD5UmZAPt2SMzmREZLA0Z5voGB_kY_7HrrS5Q@mail.gmail.com>

Folks,

I'm building SR-IOV supported compute node on HP 360g8 hardware and i
have Qlogic interface card, my compute node has 32 core & 32GB memory.

Problem:

when i launch vm-1 (with flavor 16 vCPU core) on openstack it launch
successful on numa0 node and working great. but when i launch vm-2
same flavor it start and then shutdown itself in few second, in-short
i am not able launch instance on numa1 node because my PCIe attach to
numa0node which i can see in lstopo command.

so at present i am going to lose half compute capacity if this is real
problem because i can't use numa1 to launch SR-IOV supported instance.

after google i found this link
https://blueprints.launchpad.net/nova/+spec/share-pci-device-between-numa-nodes

and according this link if i can set
hw:pci_numa_affinity_policy=preferred in flavor it will allow me to
spin up instance across the numa node but somehow its not working and
still i am not able to spin up instance, (it start instance but then
shutdown itself)

Any idea what is wrong here?


From eblock at nde.ag  Thu Oct  4 12:44:17 2018
From: eblock at nde.ag (Eugen Block)
Date: Thu, 04 Oct 2018 12:44:17 +0000
Subject: [Openstack] [Nova][Glance] Nova imports flat images from base file
 despite ceph backend
In-Reply-To: <BE4AC4DD-FB62-4C72-ACFA-37E7F5C47CE4@enter.eu>
References: <20180928115051.Horde.ZC_55UzSXeK4hiOjJt6tajA@webmail.nde.ag>
 <A24869C3-C782-48AA-A583-13D435D0356F@enter.eu>
 <20180928125224.Horde.33aqtdk0B9Ncylg-zxjA5to@webmail.nde.ag>
 <9F3C86CE-862D-469A-AD79-3F334CD5DB41@enter.eu>
 <CAHUi5cOtbC9VFaHD0yUeZDF3HqsipLRQ8h43vU-Beqr-ecz3vA@mail.gmail.com>
 <BE4AC4DD-FB62-4C72-ACFA-37E7F5C47CE4@enter.eu>
Message-ID: <20181004124417.Horde.py2wEG4JmO1oFXbjX5u1uw3@webmail.nde.ag>

Hi list,

this week I noticed something strange in our cloud (Ocata).

We use Ceph as backend for nova, glance and cinder, everything really  
works like a charm. But from time to time we've noticed that some  
instances take much longer to launch than others. So I wanted to take  
a look what's happening, turned on debug logs and found that in some  
cases (I have no idea how to reproduce yet) there is an image  
downloaded to /var/lib/nova/instances/_base which then is used to  
import it back to Ceph, that is obviously the reason for the delay.
The problem is that this new instance is not CoW, it's a flat rbd  
image. Here are some relevant logs (instance_id:  
65567fc1-017f-45dc-b0ee-570c44146119, image_id:  
0da1ba0f-c504-45ea-b138-16026aec022b)

---cut here---
[...]
2018-10-04 11:46:39.189 10293 DEBUG nova.compute.manager  
[req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] [instance:  
65567fc1-017f-45dc-b0ee-570c44146119] Start spawning the instance on  
the hypervisor. _build_and_run_instance  
/usr/lib/python2.7/site-packages/nova/compute/manager.py:1929
[...]
2018-10-04 11:46:39.192 10293 INFO nova.virt.libvirt.driver  
[req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] [instance:  
65567fc1-017f-45dc-b0ee-570c44146119] Creating image
2018-10-04 11:46:39.220 10293 DEBUG  
nova.virt.libvirt.storage.rbd_utils  
[req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image  
65567fc1-017f-45dc-b0ee-570c44146119_disk does not exist __init__  
/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77
2018-10-04 11:46:39.241 10293 DEBUG  
nova.virt.libvirt.storage.rbd_utils  
[req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image  
65567fc1-017f-45dc-b0ee-570c44146119_disk does not exist __init__  
/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77
2018-10-04 11:46:39.245 10293 DEBUG oslo_concurrency.lockutils  
[req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] Lock  
"3c60237fbf59101d3411c4f795d0a72b82752e0b" acquired by  
"nova.virt.libvirt.imagebackend.fetch_func_sync" :: waited 0.001s  
inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
2018-10-04 11:46:39.246 10293 DEBUG oslo_concurrency.lockutils  
[req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] Lock  
"3c60237fbf59101d3411c4f795d0a72b82752e0b" released by  
"nova.virt.libvirt.imagebackend.fetch_func_sync" :: held 0.001s inner  
/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
2018-10-04 11:46:39.266 10293 DEBUG  
nova.virt.libvirt.storage.rbd_utils  
[req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image  
65567fc1-017f-45dc-b0ee-570c44146119_disk does not exist __init__  
/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77
2018-10-04 11:46:39.269 10293 DEBUG oslo_concurrency.processutils  
[req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] Running cmd (subprocess): rbd  
import --pool images  
/var/lib/nova/instances/_base/3c60237fbf59101d3411c4f795d0a72b82752e0b  
65567fc1-017f-45dc-b0ee-570c44146119_disk --image-format=2 --id  
openstack --conf /etc/ceph/ceph.conf execute  
/usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:355
[...]

# no parent data
control:~ # rbd info images/65567fc1-017f-45dc-b0ee-570c44146119_disk
rbd image '65567fc1-017f-45dc-b0ee-570c44146119_disk':
         size 6144 MB in 1536 objects
         order 22 (4096 kB objects)
         block_name_prefix: rbd_data.c8f88a6b8b4567
         format: 2
         features: layering, exclusive-lock, object-map
         flags:
         create_timestamp: Thu Oct  4 11:46:39 2018

---cut here---

###################################################################

For comparison I moved the respective base file and tried to spawn a  
new instance from the same glance image:

---cut here---
[...]
2018-10-04 10:30:29.412 2336 DEBUG nova.compute.manager  
[req-942ba103-1932-4adf-b9b2-670e1a2fc126  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] [instance:  
91d0b930-97b0-4dd0-81b4-929599b7c997] Start spawning the instance on  
the hypervisor. _build_and_run_instance  
/usr/lib/python2.7/site-packages/nova/compute/manager.py:1929
[...]
2018-10-04 10:30:29.415 2336 INFO nova.virt.libvirt.driver  
[req-942ba103-1932-4adf-b9b2-670e1a2fc126  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] [instance:  
91d0b930-97b0-4dd0-81b4-929599b7c997] Creating image
2018-10-04 10:30:29.435 2336 DEBUG nova.virt.libvirt.storage.rbd_utils  
[req-942ba103-1932-4adf-b9b2-670e1a2fc126  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image  
91d0b930-97b0-4dd0-81b4-929599b7c997_disk does not exist __init__  
/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77
2018-10-04 10:30:29.455 2336 DEBUG nova.virt.libvirt.storage.rbd_utils  
[req-942ba103-1932-4adf-b9b2-670e1a2fc126  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image  
91d0b930-97b0-4dd0-81b4-929599b7c997_disk does not exist __init__  
/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77
2018-10-04 10:30:29.492 2336 DEBUG oslo_concurrency.lockutils  
[req-942ba103-1932-4adf-b9b2-670e1a2fc126  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] Lock  
"3c60237fbf59101d3411c4f795d0a72b82752e0b" acquired by  
"nova.virt.libvirt.imagebackend.fetch_func_sync" :: waited 0.035s  
inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
2018-10-04 10:30:29.527 2336 DEBUG nova.virt.libvirt.imagebackend  
[req-942ba103-1932-4adf-b9b2-670e1a2fc126  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] Image locations are: [{u'url':  
u'rbd://655cb05a-435a-41ba-83d9-8549f7c36167/images/0da1ba0f-c504-45ea-b138-16026aec022b/snap', u'metadata': {}}, {'url': u'rbd://655cb05a-435a-41ba-83d9-8549f7c36167/images/0da1ba0f-c504-45ea-b138-16026aec022b/snap', 'metadata': {}}] clone  
/usr/lib/python2.7/site-packages/nova/virt/libvirt/imagebackend.py:903
2018-10-04 10:30:29.681 2336 DEBUG nova.virt.libvirt.imagebackend  
[req-942ba103-1932-4adf-b9b2-670e1a2fc126  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] Selected location: {u'url':  
u'rbd://655cb05a-435a-41ba-83d9-8549f7c36167/images/0da1ba0f-c504-45ea-b138-16026aec022b/snap', u'metadata': {}} clone  
/usr/lib/python2.7/site-packages/nova/virt/libvirt/imagebackend.py:912
2018-10-04 10:30:29.682 2336 DEBUG nova.virt.libvirt.storage.rbd_utils  
[req-942ba103-1932-4adf-b9b2-670e1a2fc126  
df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
2e3c3f3822124a3fa9fd905164f519ae - - -] cloning  
images/0da1ba0f-c504-45ea-b138-16026aec022b at snap to  
None/91d0b930-97b0-4dd0-81b4-929599b7c997_disk clone  
/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:236
[...]


# instance has parent data
control:~ # rbd info images/91d0b930-97b0-4dd0-81b4-929599b7c997_disk
rbd image '91d0b930-97b0-4dd0-81b4-929599b7c997_disk':
         size 8192 MB in 1024 objects
         order 23 (8192 kB objects)
         block_name_prefix: rbd_data.c8abcb6b8b4567
         format: 2
         features: layering, exclusive-lock, object-map
         flags:
         create_timestamp: Thu Oct  4 10:30:29 2018
         parent: images/0da1ba0f-c504-45ea-b138-16026aec022b at snap
         overlap: 6144 MB

---cut here---

Why is there a local copy of the image in the first place? Obviously  
nova doesn't need that and creates clones successfully without them.
I would be thankful for any explanation for this behavious.

Regards,
Eugen



From manuel.sb at garvan.org.au  Mon Oct  8 05:24:45 2018
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Mon, 8 Oct 2018 05:24:45 +0000
Subject: [Openstack] vm not starting
Message-ID: <9D8A2486E35F0941A60430473E29F15B017BAC3A60@MXDB2.ad.garvan.unsw.edu.au>

Dear Openstack community,

I had to reboot my server and now I can't start one of the vms (danrod-server) which boots from volume.

vm details

[root at openstack ~(keystone_admin)]# openstack server show danrod-server
+--------------------------------------+----------------------------------------------------------+
| Field                                | Value                                                    |
+--------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                                   |
| OS-EXT-AZ:availability_zone          | nova                                                     |
| OS-EXT-SRV-ATTR:host                 | openstack.localdomain                                    |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | openstack.localdomain                                    |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000069                                        |
| OS-EXT-STS:power_state               | NOSTATE                                                  |
| OS-EXT-STS:task_state                | None                                                     |
| OS-EXT-STS:vm_state                  | stopped                                                  |
| OS-SRV-USG:launched_at               | 2018-05-29T11:22:17.000000                               |
| OS-SRV-USG:terminated_at             | None                                                     |
| accessIPv4                           |                                                          |
| accessIPv6                           |                                                          |
| addresses                            | privatenetwork=192.168.1.105, 129.94.14.238              |
| config_drive                         |                                                          |
| created                              | 2018-05-29T11:22:09Z                                     |
| flavor                               | xlarge.cpu.xxxlarge.ram (6)                              |
| hostId                               | ecef276660cd714fe626073a18c11fe1c00bec91c15516178fb6ac28 |
| id                                   | 1e59f329-072e-48ae-abf1-266eba437508                     |
| image                                |                                                          |
| key_name                             | None                                                     |
| name                                 | danrod-server                                            |
| os-extended-volumes:volumes_attached | [{u'id': u'f1ac2e94-b0ed-4089-898f-5b6467fb51e3'}]       |
| project_id                           | d58cf22d960e4de49b71658aee642e94                         |
| properties                           |                                                          |
| security_groups                      | [{u'name': u'admin'}, {u'name': u'R-Studio Server'}]     |
| status                               | SHUTOFF                                                  |
| updated                              | 2018-10-08T02:52:41Z                                     |
| user_id                              | c412f34c353244eabecd4b6dc4d36392                         |
+--------------------------------------+----------------------------------------------------------+


List of volumes

[root at openstack ~(keystone_admin)]# openstack volume list --all
+--------------------------------------+--------------+--------+------+----------------------------------------+
| ID                                   | Display Name | Status | Size | Attached to                            |
+--------------------------------------+--------------+--------+------+----------------------------------------+
| f1ac2e94-b0ed-4089-898f-5b6467fb51e3 |              | in-use |  700 | Attached to danrod-server on /dev/vda  |
+--------------------------------------+--------------+--------+------+----------------------------------------+


nova-compute.log

2018-10-08 13:51:46.476 4015 INFO os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] Multipath discovery for iSCSI not enabled.
2018-10-08 13:51:46.476 4015 INFO os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] Trying to connect to iSCSI portal 129.94.14.254:3260
2018-10-08 13:51:46.504 4015 WARNING os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] ISCSI volume not yet found at: [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0']. Will rescan & retry.  Try number: 0.
2018-10-08 13:51:47.510 4015 WARNING os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] ISCSI volume not yet found at: [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0']. Will rescan & retry.  Try number: 1.
2018-10-08 13:51:51.519 4015 WARNING os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] ISCSI volume not yet found at: [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0']. Will rescan & retry.  Try number: 2.
2018-10-08 13:52:00.527 4015 WARNING os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] ISCSI volume not yet found at: [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0']. Will rescan & retry.  Try number: 3.
2018-10-08 13:52:16.535 4015 WARNING os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] ISCSI volume not yet found at: [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0']. Will rescan & retry.  Try number: 4.
2018-10-08 13:52:23.357 4015 INFO nova.compute.resource_tracker [req-359039dc-29dc-4f06-805f-0ca943bb600f - - - - -] Auditing locally available compute resources for node openstack.localdomain
2018-10-08 13:52:23.713 4015 INFO nova.compute.resource_tracker [req-359039dc-29dc-4f06-805f-0ca943bb600f - - - - -] Total usable vcpus: 56, total allocated vcpus: 52
2018-10-08 13:52:23.713 4015 INFO nova.compute.resource_tracker [req-359039dc-29dc-4f06-805f-0ca943bb600f - - - - -] Final resource view: name=openstack.localdomain phys_ram=524173MB used_ram=454608MB phys_disk=9312GB used_disk=1540GB total_vcpus=56 used_vcpus=52 pci_stats=[]
2018-10-08 13:52:23.733 4015 INFO nova.compute.resource_tracker [req-359039dc-29dc-4f06-805f-0ca943bb600f - - - - -] Compute_service record updated for openstack.localdomain:openstack.localdomain
2018-10-08 13:52:41.665 4015 INFO nova.compute.manager [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] [instance: 1e59f329-072e-48ae-abf1-266eba437508] Successfully reverted task state from powering-on on failure for instance.
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] Exception during message handling
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server Traceback (most recent call last):
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     res = self.dispatcher.dispatch(message)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 150, in dispatch
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return self._do_dispatch(endpoint, method, ctxt, args)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 121, in _do_dispatch
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     result = func(ctxt, **new_args)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 75, in wrapped
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     function_name, call_dict, binary)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self.force_reraise()
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     six.reraise(self.type_, self.value, self.tb)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 66, in wrapped
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return f(self, context, *args, **kw)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 188, in decorated_function
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     LOG.warning(msg, e, instance=instance)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self.force_reraise()
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     six.reraise(self.type_, self.value, self.tb)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 157, in decorated_function
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return function(self, context, *args, **kwargs)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/utils.py", line 613, in decorated_function
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return function(self, context, *args, **kwargs)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 216, in decorated_function
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     kwargs['instance'], e, sys.exc_info())
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self.force_reraise()
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     six.reraise(self.type_, self.value, self.tb)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 204, in decorated_function
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return function(self, context, *args, **kwargs)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2475, in start_instance
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self._power_on(context, instance)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2445, in _power_on
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     block_device_info)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2434, in power_on
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self._hard_reboot(context, instance, network_info, block_device_info)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2307, in _hard_reboot
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     block_device_info=block_device_info)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4658, in _get_guest_xml
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     context)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4483, in _get_guest_config
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     flavor, guest.os_type)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3523, in _get_guest_storage_config
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self._connect_volume(connection_info, info)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1099, in _connect_volume
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     vol_driver.connect_volume(connection_info, disk_info)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/iscsi.py", line 64, in connect_volume
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     device_info = self.connector.connect_volume(connection_info['data'])
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/os_brick/utils.py", line 137, in trace_logging_wrapper
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return f(*args, **kwargs)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py", line 271, in inner
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return f(*args, **kwargs)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/os_brick/initiator/connectors/iscsi.py", line 404, in connect_volume
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     raise exception.VolumeDeviceNotFound(device=host_devices)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server VolumeDeviceNotFound: Volume device not found at [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0'].
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server



Cinder logs

2018-10-08 08:52:58.368 7069 ERROR oslo.messaging._drivers.impl_rabbit [-] [3dce0b7f-7eea-45e9-9fa5-220e783c0401] AMQP server 129.94.14.254:5672 closed the connection. Check login credentials: Socket closed
2018-10-08 08:52:59.395 7069 ERROR oslo.messaging._drivers.impl_rabbit [-] [3dce0b7f-7eea-45e9-9fa5-220e783c0401] AMQP server on 129.94.14.254:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 2 seconds. Client port: 60428
2018-10-08 08:53:01.404 7069 ERROR oslo.messaging._drivers.impl_rabbit [-] [3dce0b7f-7eea-45e9-9fa5-220e783c0401] AMQP server on 129.94.14.254:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 4 seconds. Client port: 60428
2018-10-08 08:53:04.131 7069 ERROR cinder.service [req-f6138d6c-a09f-4ed4-881f-ed095d172461 - - - - -] model server went away
2018-10-08 08:53:04.131 7069 ERROR cinder.service Traceback (most recent call last):
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/service.py", line 445, in report_state
2018-10-08 08:53:04.131 7069 ERROR cinder.service     service_ref = objects.Service.get_by_id(ctxt, self.service_id)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/objects/base.py", line 287, in get_by_id
2018-10-08 08:53:04.131 7069 ERROR cinder.service     orm_obj = db.get_by_id(context, cls.model, id, *args, **kwargs)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/db/api.py", line 1624, in get_by_id
2018-10-08 08:53:04.131 7069 ERROR cinder.service     return IMPL.get_by_id(context, model, id, *args, **kwargs)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/db/sqlalchemy/api.py", line 196, in wrapper
2018-10-08 08:53:04.131 7069 ERROR cinder.service     return f(*args, **kwargs)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/db/sqlalchemy/api.py", line 6204, in get_by_id
2018-10-08 08:53:04.131 7069 ERROR cinder.service     return _GET_METHODS[model](context, id, *args, **kwargs)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/db/sqlalchemy/api.py", line 178, in wrapper
2018-10-08 08:53:04.131 7069 ERROR cinder.service     return f(*args, **kwargs)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/db/sqlalchemy/api.py", line 483, in service_get
2018-10-08 08:53:04.131 7069 ERROR cinder.service     service = None if not query else query.first()
...

However the connection to the rabbitmq server is fine?

[root at openstack ~(keystone_admin)]# sudo ss -nolpt | grep 5672
LISTEN     0      128          *:25672                    *:*                   users:(("beam.smp",pid=2465,fd=43))
LISTEN     0      128         :::5672                    :::*                   users:(("beam.smp",pid=2465,fd=52))
[root at openstack ~(keystone_admin)]# telnet 129.94.14.254 5672
Trying 129.94.14.254...
Connected to 129.94.14.254.
Escape character is '^]'.

Any advice in regards how to fix this issue and be able to bring the vm back online would be highly appreciated?

Thank you very much

Manuel Sopena Ballesteros | Big data Engineer
Garvan Institute of Medical Research
The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010
T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: manuel.sb at garvan.org.au<mailto:manuel.sb at garvan.org.au>

NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181008/28dc2d1c/attachment.html>

From manuel.sb at garvan.org.au  Mon Oct  8 05:29:45 2018
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Mon, 8 Oct 2018 05:29:45 +0000
Subject: [Openstack] vm not starting
Message-ID: <9D8A2486E35F0941A60430473E29F15B017BAC3A91@MXDB2.ad.garvan.unsw.edu.au>

Sorry forgot to add the volume details attached to the vm

[root at openstack ~(keystone_admin)]# openstack volume show f1ac2e94-b0ed-4089-898f-5b6467fb51e3
+--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field                          | Value                                                                                                                                                                                                                    |
+--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments                    | [{u'server_id': u'1e59f329-072e-48ae-abf1-266eba437508', u'attachment_id': u'9634e683-2d71-483b-8c1a-7aedd9c8c7d8', u'attached_at': u'2018-05-29T11:22:12.000000', u'host_name': None, u'volume_id':                     |
|                                | u'f1ac2e94-b0ed-4089-898f-5b6467fb51e3', u'device': u'/dev/vda', u'id': u'f1ac2e94-b0ed-4089-898f-5b6467fb51e3'}]                                                                                                        |
| availability_zone              | nova                                                                                                                                                                                                                     |
| bootable                       | true                                                                                                                                                                                                                     |
| consistencygroup_id            | None                                                                                                                                                                                                                     |
| created_at                     | 2017-03-01T00:53:07.000000                                                                                                                                                                                               |
| description                    |                                                                                                                                                                                                                          |
| encrypted                      | False                                                                                                                                                                                                                    |
| id                             | f1ac2e94-b0ed-4089-898f-5b6467fb51e3                                                                                                                                                                                     |
| migration_status               | None                                                                                                                                                                                                                     |
| multiattach                    | False                                                                                                                                                                                                                    |
| name                           |                                                                                                                                                                                                                          |
| os-vol-host-attr:host          | openstack.localdomain at lvm#lvm                                                                                                                                                                                            |
| os-vol-mig-status-attr:migstat | None                                                                                                                                                                                                                     |
| os-vol-mig-status-attr:name_id | None                                                                                                                                                                                                                     |
| os-vol-tenant-attr:tenant_id   | 847121649d804ebca4da5260979118d1                                                                                                                                                                                         |
| properties                     | attached_mode='rw', readonly='False'                                                                                                                                                                                     |
| replication_status             | disabled                                                                                                                                                                                                                 |
| size                           | 700                                                                                                                                                                                                                      |
| snapshot_id                    | None                                                                                                                                                                                                                     |
| source_volid                   | None                                                                                                                                                                                                                     |
| status                         | in-use                                                                                                                                                                                                                   |
| type                           | iscsi                                                                                                                                                                                                                    |
| updated_at                     | 2018-05-29T11:22:12.000000                                                                                                                                                                                               |
| user_id                        | cce14e7b44254074941b1cff2cf519ae                                                                                                                                                                                         |
| volume_image_metadata          | {u'container_format': u'bare', u'min_ram': u'0', u'disk_format': u'qcow2', u'image_name': u'centos7', u'image_id': u'7047b9a6-f0a2-415a-8ea7-af834146260f', u'checksum': u'bc62ad193b085680952edfa7face0f23',            |
|                                | u'min_disk': u'0', u'size': u'1361182720'}                                                                                                                                                                               |
+--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Manuel

From: Manuel Sopena Ballesteros
Sent: Monday, October 8, 2018 4:25 PM
To: openstack at lists.openstack.org
Subject: vm not starting

Dear Openstack community,

I had to reboot my server and now I can't start one of the vms (danrod-server) which boots from volume.

vm details

[root at openstack ~(keystone_admin)]# openstack server show danrod-server
+--------------------------------------+----------------------------------------------------------+
| Field                                | Value                                                    |
+--------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                                   |
| OS-EXT-AZ:availability_zone          | nova                                                     |
| OS-EXT-SRV-ATTR:host                 | openstack.localdomain                                    |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | openstack.localdomain                                    |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000069                                        |
| OS-EXT-STS:power_state               | NOSTATE                                                  |
| OS-EXT-STS:task_state                | None                                                     |
| OS-EXT-STS:vm_state                  | stopped                                                  |
| OS-SRV-USG:launched_at               | 2018-05-29T11:22:17.000000                               |
| OS-SRV-USG:terminated_at             | None                                                     |
| accessIPv4                           |                                                          |
| accessIPv6                           |                                                          |
| addresses                            | privatenetwork=192.168.1.105, 129.94.14.238              |
| config_drive                         |                                                          |
| created                              | 2018-05-29T11:22:09Z                                     |
| flavor                               | xlarge.cpu.xxxlarge.ram (6)                              |
| hostId                               | ecef276660cd714fe626073a18c11fe1c00bec91c15516178fb6ac28 |
| id                                   | 1e59f329-072e-48ae-abf1-266eba437508                     |
| image                                |                                                          |
| key_name                             | None                                                     |
| name                                 | danrod-server                                            |
| os-extended-volumes:volumes_attached | [{u'id': u'f1ac2e94-b0ed-4089-898f-5b6467fb51e3'}]       |
| project_id                           | d58cf22d960e4de49b71658aee642e94                         |
| properties                           |                                                          |
| security_groups                      | [{u'name': u'admin'}, {u'name': u'R-Studio Server'}]     |
| status                               | SHUTOFF                                                  |
| updated                              | 2018-10-08T02:52:41Z                                     |
| user_id                              | c412f34c353244eabecd4b6dc4d36392                         |
+--------------------------------------+----------------------------------------------------------+


List of volumes

[root at openstack ~(keystone_admin)]# openstack volume list --all
+--------------------------------------+--------------+--------+------+----------------------------------------+
| ID                                   | Display Name | Status | Size | Attached to                            |
+--------------------------------------+--------------+--------+------+----------------------------------------+
| f1ac2e94-b0ed-4089-898f-5b6467fb51e3 |              | in-use |  700 | Attached to danrod-server on /dev/vda  |
+--------------------------------------+--------------+--------+------+----------------------------------------+


nova-compute.log

2018-10-08 13:51:46.476 4015 INFO os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] Multipath discovery for iSCSI not enabled.
2018-10-08 13:51:46.476 4015 INFO os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] Trying to connect to iSCSI portal 129.94.14.254:3260
2018-10-08 13:51:46.504 4015 WARNING os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] ISCSI volume not yet found at: [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0']. Will rescan & retry.  Try number: 0.
2018-10-08 13:51:47.510 4015 WARNING os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] ISCSI volume not yet found at: [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0']. Will rescan & retry.  Try number: 1.
2018-10-08 13:51:51.519 4015 WARNING os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] ISCSI volume not yet found at: [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0']. Will rescan & retry.  Try number: 2.
2018-10-08 13:52:00.527 4015 WARNING os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] ISCSI volume not yet found at: [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0']. Will rescan & retry.  Try number: 3.
2018-10-08 13:52:16.535 4015 WARNING os_brick.initiator.connectors.iscsi [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] ISCSI volume not yet found at: [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0']. Will rescan & retry.  Try number: 4.
2018-10-08 13:52:23.357 4015 INFO nova.compute.resource_tracker [req-359039dc-29dc-4f06-805f-0ca943bb600f - - - - -] Auditing locally available compute resources for node openstack.localdomain
2018-10-08 13:52:23.713 4015 INFO nova.compute.resource_tracker [req-359039dc-29dc-4f06-805f-0ca943bb600f - - - - -] Total usable vcpus: 56, total allocated vcpus: 52
2018-10-08 13:52:23.713 4015 INFO nova.compute.resource_tracker [req-359039dc-29dc-4f06-805f-0ca943bb600f - - - - -] Final resource view: name=openstack.localdomain phys_ram=524173MB used_ram=454608MB phys_disk=9312GB used_disk=1540GB total_vcpus=56 used_vcpus=52 pci_stats=[]
2018-10-08 13:52:23.733 4015 INFO nova.compute.resource_tracker [req-359039dc-29dc-4f06-805f-0ca943bb600f - - - - -] Compute_service record updated for openstack.localdomain:openstack.localdomain
2018-10-08 13:52:41.665 4015 INFO nova.compute.manager [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] [instance: 1e59f329-072e-48ae-abf1-266eba437508] Successfully reverted task state from powering-on on failure for instance.
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server [req-d9ed864b-9a4f-4182-b91b-9a2f1e38fb02 c412f34c353244eabecd4b6dc4d36392 d58cf22d960e4de49b71658aee642e94 - - -] Exception during message handling
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server Traceback (most recent call last):
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     res = self.dispatcher.dispatch(message)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 150, in dispatch
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return self._do_dispatch(endpoint, method, ctxt, args)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 121, in _do_dispatch
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     result = func(ctxt, **new_args)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 75, in wrapped
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     function_name, call_dict, binary)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self.force_reraise()
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     six.reraise(self.type_, self.value, self.tb)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 66, in wrapped
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return f(self, context, *args, **kw)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 188, in decorated_function
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     LOG.warning(msg, e, instance=instance)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self.force_reraise()
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     six.reraise(self.type_, self.value, self.tb)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 157, in decorated_function
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return function(self, context, *args, **kwargs)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/utils.py", line 613, in decorated_function
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return function(self, context, *args, **kwargs)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 216, in decorated_function
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     kwargs['instance'], e, sys.exc_info())
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self.force_reraise()
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     six.reraise(self.type_, self.value, self.tb)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 204, in decorated_function
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return function(self, context, *args, **kwargs)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2475, in start_instance
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self._power_on(context, instance)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2445, in _power_on
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     block_device_info)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2434, in power_on
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self._hard_reboot(context, instance, network_info, block_device_info)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2307, in _hard_reboot
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     block_device_info=block_device_info)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4658, in _get_guest_xml
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     context)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4483, in _get_guest_config
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     flavor, guest.os_type)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3523, in _get_guest_storage_config
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     self._connect_volume(connection_info, info)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1099, in _connect_volume
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     vol_driver.connect_volume(connection_info, disk_info)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/iscsi.py", line 64, in connect_volume
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     device_info = self.connector.connect_volume(connection_info['data'])
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/os_brick/utils.py", line 137, in trace_logging_wrapper
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return f(*args, **kwargs)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py", line 271, in inner
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     return f(*args, **kwargs)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/os_brick/initiator/connectors/iscsi.py", line 404, in connect_volume
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server     raise exception.VolumeDeviceNotFound(device=host_devices)
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server VolumeDeviceNotFound: Volume device not found at [u'/dev/disk/by-path/ip-129.94.14.254:3260-iscsi-iqn.2010-10.org.openstack:volume-f1ac2e94-b0ed-4089-898f-5b6467fb51e3-lun-0'].
2018-10-08 13:52:41.672 4015 ERROR oslo_messaging.rpc.server



Cinder logs

2018-10-08 08:52:58.368 7069 ERROR oslo.messaging._drivers.impl_rabbit [-] [3dce0b7f-7eea-45e9-9fa5-220e783c0401] AMQP server 129.94.14.254:5672 closed the connection. Check login credentials: Socket closed
2018-10-08 08:52:59.395 7069 ERROR oslo.messaging._drivers.impl_rabbit [-] [3dce0b7f-7eea-45e9-9fa5-220e783c0401] AMQP server on 129.94.14.254:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 2 seconds. Client port: 60428
2018-10-08 08:53:01.404 7069 ERROR oslo.messaging._drivers.impl_rabbit [-] [3dce0b7f-7eea-45e9-9fa5-220e783c0401] AMQP server on 129.94.14.254:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 4 seconds. Client port: 60428
2018-10-08 08:53:04.131 7069 ERROR cinder.service [req-f6138d6c-a09f-4ed4-881f-ed095d172461 - - - - -] model server went away
2018-10-08 08:53:04.131 7069 ERROR cinder.service Traceback (most recent call last):
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/service.py", line 445, in report_state
2018-10-08 08:53:04.131 7069 ERROR cinder.service     service_ref = objects.Service.get_by_id(ctxt, self.service_id)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/objects/base.py", line 287, in get_by_id
2018-10-08 08:53:04.131 7069 ERROR cinder.service     orm_obj = db.get_by_id(context, cls.model, id, *args, **kwargs)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/db/api.py", line 1624, in get_by_id
2018-10-08 08:53:04.131 7069 ERROR cinder.service     return IMPL.get_by_id(context, model, id, *args, **kwargs)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/db/sqlalchemy/api.py", line 196, in wrapper
2018-10-08 08:53:04.131 7069 ERROR cinder.service     return f(*args, **kwargs)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/db/sqlalchemy/api.py", line 6204, in get_by_id
2018-10-08 08:53:04.131 7069 ERROR cinder.service     return _GET_METHODS[model](context, id, *args, **kwargs)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/db/sqlalchemy/api.py", line 178, in wrapper
2018-10-08 08:53:04.131 7069 ERROR cinder.service     return f(*args, **kwargs)
2018-10-08 08:53:04.131 7069 ERROR cinder.service   File "/usr/lib/python2.7/site-packages/cinder/db/sqlalchemy/api.py", line 483, in service_get
2018-10-08 08:53:04.131 7069 ERROR cinder.service     service = None if not query else query.first()
...

However the connection to the rabbitmq server is fine?

[root at openstack ~(keystone_admin)]# sudo ss -nolpt | grep 5672
LISTEN     0      128          *:25672                    *:*                   users:(("beam.smp",pid=2465,fd=43))
LISTEN     0      128         :::5672                    :::*                   users:(("beam.smp",pid=2465,fd=52))
[root at openstack ~(keystone_admin)]# telnet 129.94.14.254 5672
Trying 129.94.14.254...
Connected to 129.94.14.254.
Escape character is '^]'.

Any advice in regards how to fix this issue and be able to bring the vm back online would be highly appreciated?

Thank you very much

Manuel Sopena Ballesteros | Big data Engineer
Garvan Institute of Medical Research
The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010
T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: manuel.sb at garvan.org.au<mailto:manuel.sb at garvan.org.au>

NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181008/89b592e1/attachment.html>

From robert at componentsoft.io  Mon Oct  8 16:33:07 2018
From: robert at componentsoft.io (Robert Varjasi)
Date: Mon, 8 Oct 2018 18:33:07 +0200
Subject: [Openstack] nova-api-os-compute slowdown
Message-ID: <c6b6426e-49d9-a7f1-f741-135181a06216@componentsoft.io>

Hi,

After a few tempest run I noticed slowdowns in the nova-api-os-compute
uwsgi  processes. I check the processes with py-spy and found that a lot
of process blocked on read(). Here is my py-spy output from one of my
nova-api-os-compute uwsgi process: http://paste.openstack.org/show/731677/

And the stack trace:

thread_id = Thread-2 filename = /usr/lib/python2.7/threading.py lineno =
774 function = __bootstrap line = self.__bootstrap_inner()
thread_id = Thread-2 filename = /usr/lib/python2.7/threading.py lineno =
801 function = __bootstrap_inner line = self.run()
thread_id = Thread-2 filename = /usr/lib/python2.7/threading.py lineno =
754 function = run line = self.__target(*self.__args, **self.__kwargs)
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py
lineno = 382 function = poll line =
self.conn.consume(timeout=current_timeout)
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
lineno = 1083 function = consume line = error_callback=_error_callback)
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
lineno = 807 function = ensure line = ret, channel = autoretry_method()
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/connection.py
lineno = 494 function = _ensured line = return fun(*args, **kwargs)
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/connection.py
lineno = 570 function = __call__ line = return fun(*args,
channel=channels[0], **kwargs), channels[0]
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
lineno = 796 function = execute_method line = method()
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
lineno = 1068 function = _consume line =
self.connection.drain_events(timeout=poll_timeout)
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/connection.py
lineno = 301 function = drain_events line = return
self.transport.drain_events(self.connection, **kwargs)
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/transport/pyamqp.py
lineno = 103 function = drain_events line = return
connection.drain_events(**kwargs)
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/connection.py
lineno = 471 function = drain_events line = while not
self.blocking_read(timeout):
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/connection.py
lineno = 476 function = blocking_read line = frame =
self.transport.read_frame()
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/transport.py
lineno = 226 function = read_frame line = frame_header = read(7, True)
thread_id = Thread-2 filename =
/openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/transport.py
lineno = 346 function = _read line = s = recv(n - len(rbuf))  # see note
above
thread_id = Thread-2 filename = /usr/lib/python2.7/ssl.py lineno = 643
function = read line = v = self._sslobj.read(len)

I am using nova 17.0.4.dev1, amqp (2.2.2), oslo.messaging (5.35.0),
kombu (4.1.0). I have 3 controller nodes. The openstack deployed by OSA
17.0.4.

I can reproduce the read() block if I click on "Log" in Horizon to see
the console outputs from one of my VM or run a tempest test:
tempest.api.compute.admin.test_hypervisor.HypervisorAdminTestJSON.test_get_hypervisor_uptime.

The nova-api response time increasing when more and more nova-api
processes get blocked at this read. Is it a normal behavior?

--- 
Regards,
Robert Varjasi
consultant at Component Soft Ltd.



From jaypipes at gmail.com  Mon Oct  8 17:28:22 2018
From: jaypipes at gmail.com (Jay Pipes)
Date: Mon, 8 Oct 2018 13:28:22 -0400
Subject: [Openstack] [diskimage-builder] Element pip-and-virtualenv
 failed to install pip
In-Reply-To: <CAAHnLin33Dsd8UCao-k8K-nmOBY2hpfdtM=9doeUE0G_H2a2KQ@mail.gmail.com>
References: <CAAHnLin33Dsd8UCao-k8K-nmOBY2hpfdtM=9doeUE0G_H2a2KQ@mail.gmail.com>
Message-ID: <a73a05fd-c9e2-fd66-462b-cba622be938d@gmail.com>

On 09/07/2018 03:46 PM, Hang Yang wrote:
> Hi there,
> 
> I'm new to the DIB tool and ran into an issue when used 2.16.0 DIB tool 
> to build a CentOS based image with pip-and-virtualenv element. It failed 
> at 
> https://github.com/openstack/diskimage-builder/blob/master/diskimage_builder/elements/pip-and-virtualenv/install.d/pip-and-virtualenv-source-install/04-install-pip#L78 
> due to cannot find pip command.
> 
> I found the /tmp/get_pip.py was there but totally empty. I have to 
> manually add a wget step to retreat the get_pip.py right before the 
> failed step then it worked. But should the get_pip.py be downloaded 
> automatically by this 
> https://github.com/openstack/diskimage-builder/blob/master/diskimage_builder/elements/pip-and-virtualenv/source-repository-pip-and-virtualenv 
> ? Does anyone know how could this issue happen? Thanks in advance for 
> any help.

Hi Hang,

Are you using a package or a source-based installation for your dib? The 
reason I ask is because from the docs it seems that the installation 
procedure for pip is quite different depending on whether you're using a 
package or source-based install.

Best,
-jay


From eblock at nde.ag  Tue Oct  9 08:01:01 2018
From: eblock at nde.ag (Eugen Block)
Date: Tue, 09 Oct 2018 08:01:01 +0000
Subject: [Openstack] [Nova][Glance] Nova imports flat images from base
 file despite ceph backend
In-Reply-To: <20181004124417.Horde.py2wEG4JmO1oFXbjX5u1uw3@webmail.nde.ag>
References: <20180928115051.Horde.ZC_55UzSXeK4hiOjJt6tajA@webmail.nde.ag>
 <A24869C3-C782-48AA-A583-13D435D0356F@enter.eu>
 <20180928125224.Horde.33aqtdk0B9Ncylg-zxjA5to@webmail.nde.ag>
 <9F3C86CE-862D-469A-AD79-3F334CD5DB41@enter.eu>
 <CAHUi5cOtbC9VFaHD0yUeZDF3HqsipLRQ8h43vU-Beqr-ecz3vA@mail.gmail.com>
 <BE4AC4DD-FB62-4C72-ACFA-37E7F5C47CE4@enter.eu>
 <20181004124417.Horde.py2wEG4JmO1oFXbjX5u1uw3@webmail.nde.ag>
Message-ID: <20181009080101.Horde.---iO9LIrKkWvTsNJwWk_Mj@webmail.nde.ag>

Hi,

I just wanted to follow up on this for documentation purpose. Although  
I still don't have all answers there's something I can explain.

When I upload a new image (iso) to create a new base image for glance,  
and I use "--disk-format iso", this will lead to the described  
behavior, nova will report something like:

> rbd image clone requires image format to be 'raw' but image  
> rbd://<Cluster_ID>/images/<IMAGE_ID>/snap is 'iso' is_cloneable

If I launch a new instance from that iso, nova will download it to the  
filesystem (/var/lib/nova/instances/_base) which will take some time.  
Then I attach an empty volume, finish the installation, destroy the  
instance and upload the volume to glance, that new glance image has a  
default "disk-format = raw".

Now when I launch an instance from this new image (raw) I usually get  
a CoW clone on RBD layer. The _base file of the ISO will eventually be  
removed by nova if the base file is old enough. This is how I always  
created new instances, not knowing that the ISOs should have the "raw"  
disk-format. Despite the wrong format of ISOs my procedure usually  
leads to CoW clones anyway since I upload volumes to glance.
I tried to reproduce it with the exact same workflow, but everything  
worked as expected (including the download of the iso image to local  
filesystem, I learned that now).

So it's still unclear why nova downloaded a raw glance image to the  
local filesystem during the previous attempt.

I always knew that with Ceph as backend it's recommended to use raw  
images but I always assumed the "disk-format" was not more than a  
display option. Well, now I know that, but this still doesn't explain  
the downloaded base image.
If anyone has an idea how to reproduce such behavior or an  
explanation, I'd love to hear it.

Regards,
Eugen


Zitat von Eugen Block <eblock at nde.ag>:

> Hi list,
>
> this week I noticed something strange in our cloud (Ocata).
>
> We use Ceph as backend for nova, glance and cinder, everything  
> really works like a charm. But from time to time we've noticed that  
> some instances take much longer to launch than others. So I wanted  
> to take a look what's happening, turned on debug logs and found that  
> in some cases (I have no idea how to reproduce yet) there is an  
> image downloaded to /var/lib/nova/instances/_base which then is used  
> to import it back to Ceph, that is obviously the reason for the delay.
> The problem is that this new instance is not CoW, it's a flat rbd  
> image. Here are some relevant logs (instance_id:  
> 65567fc1-017f-45dc-b0ee-570c44146119, image_id:  
> 0da1ba0f-c504-45ea-b138-16026aec022b)
>
> ---cut here---
> [...]
> 2018-10-04 11:46:39.189 10293 DEBUG nova.compute.manager  
> [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance:  
> 65567fc1-017f-45dc-b0ee-570c44146119] Start spawning the instance on  
> the hypervisor. _build_and_run_instance  
> /usr/lib/python2.7/site-packages/nova/compute/manager.py:1929
> [...]
> 2018-10-04 11:46:39.192 10293 INFO nova.virt.libvirt.driver  
> [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance:  
> 65567fc1-017f-45dc-b0ee-570c44146119] Creating image
> 2018-10-04 11:46:39.220 10293 DEBUG  
> nova.virt.libvirt.storage.rbd_utils  
> [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image  
> 65567fc1-017f-45dc-b0ee-570c44146119_disk does not exist __init__  
> /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77
> 2018-10-04 11:46:39.241 10293 DEBUG  
> nova.virt.libvirt.storage.rbd_utils  
> [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image  
> 65567fc1-017f-45dc-b0ee-570c44146119_disk does not exist __init__  
> /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77
> 2018-10-04 11:46:39.245 10293 DEBUG oslo_concurrency.lockutils  
> [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] Lock  
> "3c60237fbf59101d3411c4f795d0a72b82752e0b" acquired by  
> "nova.virt.libvirt.imagebackend.fetch_func_sync" :: waited 0.001s  
> inner  
> /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
> 2018-10-04 11:46:39.246 10293 DEBUG oslo_concurrency.lockutils  
> [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] Lock  
> "3c60237fbf59101d3411c4f795d0a72b82752e0b" released by  
> "nova.virt.libvirt.imagebackend.fetch_func_sync" :: held 0.001s  
> inner  
> /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
> 2018-10-04 11:46:39.266 10293 DEBUG  
> nova.virt.libvirt.storage.rbd_utils  
> [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image  
> 65567fc1-017f-45dc-b0ee-570c44146119_disk does not exist __init__  
> /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77
> 2018-10-04 11:46:39.269 10293 DEBUG oslo_concurrency.processutils  
> [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] Running cmd (subprocess):  
> rbd import --pool images  
> /var/lib/nova/instances/_base/3c60237fbf59101d3411c4f795d0a72b82752e0b  
> 65567fc1-017f-45dc-b0ee-570c44146119_disk --image-format=2 --id  
> openstack --conf /etc/ceph/ceph.conf execute  
> /usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:355
> [...]
>
> # no parent data
> control:~ # rbd info images/65567fc1-017f-45dc-b0ee-570c44146119_disk
> rbd image '65567fc1-017f-45dc-b0ee-570c44146119_disk':
>         size 6144 MB in 1536 objects
>         order 22 (4096 kB objects)
>         block_name_prefix: rbd_data.c8f88a6b8b4567
>         format: 2
>         features: layering, exclusive-lock, object-map
>         flags:
>         create_timestamp: Thu Oct  4 11:46:39 2018
>
> ---cut here---
>
> ###################################################################
>
> For comparison I moved the respective base file and tried to spawn a  
> new instance from the same glance image:
>
> ---cut here---
> [...]
> 2018-10-04 10:30:29.412 2336 DEBUG nova.compute.manager  
> [req-942ba103-1932-4adf-b9b2-670e1a2fc126  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance:  
> 91d0b930-97b0-4dd0-81b4-929599b7c997] Start spawning the instance on  
> the hypervisor. _build_and_run_instance  
> /usr/lib/python2.7/site-packages/nova/compute/manager.py:1929
> [...]
> 2018-10-04 10:30:29.415 2336 INFO nova.virt.libvirt.driver  
> [req-942ba103-1932-4adf-b9b2-670e1a2fc126  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance:  
> 91d0b930-97b0-4dd0-81b4-929599b7c997] Creating image
> 2018-10-04 10:30:29.435 2336 DEBUG  
> nova.virt.libvirt.storage.rbd_utils  
> [req-942ba103-1932-4adf-b9b2-670e1a2fc126  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image  
> 91d0b930-97b0-4dd0-81b4-929599b7c997_disk does not exist __init__  
> /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77
> 2018-10-04 10:30:29.455 2336 DEBUG  
> nova.virt.libvirt.storage.rbd_utils  
> [req-942ba103-1932-4adf-b9b2-670e1a2fc126  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image  
> 91d0b930-97b0-4dd0-81b4-929599b7c997_disk does not exist __init__  
> /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77
> 2018-10-04 10:30:29.492 2336 DEBUG oslo_concurrency.lockutils  
> [req-942ba103-1932-4adf-b9b2-670e1a2fc126  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] Lock  
> "3c60237fbf59101d3411c4f795d0a72b82752e0b" acquired by  
> "nova.virt.libvirt.imagebackend.fetch_func_sync" :: waited 0.035s  
> inner  
> /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
> 2018-10-04 10:30:29.527 2336 DEBUG nova.virt.libvirt.imagebackend  
> [req-942ba103-1932-4adf-b9b2-670e1a2fc126  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] Image locations are:  
> [{u'url':  
> u'rbd://655cb05a-435a-41ba-83d9-8549f7c36167/images/0da1ba0f-c504-45ea-b138-16026aec022b/snap', u'metadata': {}}, {'url': u'rbd://655cb05a-435a-41ba-83d9-8549f7c36167/images/0da1ba0f-c504-45ea-b138-16026aec022b/snap', 'metadata': {}}] clone  
> /usr/lib/python2.7/site-packages/nova/virt/libvirt/imagebackend.py:903
> 2018-10-04 10:30:29.681 2336 DEBUG nova.virt.libvirt.imagebackend  
> [req-942ba103-1932-4adf-b9b2-670e1a2fc126  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] Selected location: {u'url':  
> u'rbd://655cb05a-435a-41ba-83d9-8549f7c36167/images/0da1ba0f-c504-45ea-b138-16026aec022b/snap', u'metadata': {}} clone  
> /usr/lib/python2.7/site-packages/nova/virt/libvirt/imagebackend.py:912
> 2018-10-04 10:30:29.682 2336 DEBUG  
> nova.virt.libvirt.storage.rbd_utils  
> [req-942ba103-1932-4adf-b9b2-670e1a2fc126  
> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e  
> 2e3c3f3822124a3fa9fd905164f519ae - - -] cloning  
> images/0da1ba0f-c504-45ea-b138-16026aec022b at snap to  
> None/91d0b930-97b0-4dd0-81b4-929599b7c997_disk clone  
> /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:236
> [...]
>
>
> # instance has parent data
> control:~ # rbd info images/91d0b930-97b0-4dd0-81b4-929599b7c997_disk
> rbd image '91d0b930-97b0-4dd0-81b4-929599b7c997_disk':
>         size 8192 MB in 1024 objects
>         order 23 (8192 kB objects)
>         block_name_prefix: rbd_data.c8abcb6b8b4567
>         format: 2
>         features: layering, exclusive-lock, object-map
>         flags:
>         create_timestamp: Thu Oct  4 10:30:29 2018
>         parent: images/0da1ba0f-c504-45ea-b138-16026aec022b at snap
>         overlap: 6144 MB
>
> ---cut here---
>
> Why is there a local copy of the image in the first place? Obviously  
> nova doesn't need that and creates clones successfully without them.
> I would be thankful for any explanation for this behavious.
>
> Regards,
> Eugen





From matthias.leopold at meduniwien.ac.at  Tue Oct  9 14:48:15 2018
From: matthias.leopold at meduniwien.ac.at (Matthias Leopold)
Date: Tue, 9 Oct 2018 16:48:15 +0200
Subject: [Openstack] Pike: Keystone setup problem (in Docker container...)
Message-ID: <285a4fb8-f8e0-453e-04a9-9fda1acaee24@meduniwien.ac.at>

Hi,

I'm trying to setup Cinder as a standalone service with Docker using the 
blockbox system (contrib/blockbox in the Cinder source distribution). I 
was inspired by this manual: 
https://thenewstack.io/deploying-cinder-stand-alone-storage-service/.

This works quite well with Cinder’s noauth option as described above. 
Now i want/have to add Keystone to the mix. I built the Keystone image 
and added a custom init script to initialize Keystone when fired up and 
a certain environment is set. For this i followed instructions from 
https://docs.openstack.org/keystone/pike/install/keystone-install-rdo.html.

This works to the point where "keystone-manage bootstrap" is called.
This fails with:

CRITICAL keystone [req-45247f41-0e4f-4cc7-8bb8-60c3793489b9 - - - - -] 
Unhandled error: TypeError: unpackb() got an unexpected keyword argument 
'raw'

Can anybody tell me what's wrong?

Of course my setup is rather special so I'll mention some more details:
Docker host system: CentOS 7
Docker version: 18.06.1-ce, build e68fc7a
Keystone branch: stable/pike
Platform (for docker images): centos:7

I additionally rolled the python2-pyasn1 package into the Keystone 
image, but that didn't help. The "keystone" database in the "mariadb" 
container is initialized and accessible from the "keystone" container, i 
checked that.

I know this is a rather exotic case, but maybe someone recognizes the 
obvious problem. I'm not an OpenStack expert (want to use Cinder for oVirt).

thx
Matthias



From jayachander.it at gmail.com  Wed Oct 10 00:54:52 2018
From: jayachander.it at gmail.com (Jay See)
Date: Wed, 10 Oct 2018 02:54:52 +0200
Subject: [Openstack] [openstack] openstack setups at Universities
Message-ID: <CAD33W0y1cxtnrdaA-cYb_PWC3Mz+NoMWTkKgkrfm41FAOLaj8w@mail.gmail.com>

Hai everyone,

May be a different question , not completely related to issues associated
with openstack.

Does anyone know any university or universities using opnstack for cloud
deployment and resource sharing.

BR,
Jay.


-- 
​
P  *SAVE PAPER – Please do not print this e-mail unless absolutely
necessary.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181010/9365483d/attachment.html>

From fungi at yuggoth.org  Wed Oct 10 01:29:02 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 10 Oct 2018 01:29:02 +0000
Subject: [Openstack] [openstack] openstack setups at Universities
In-Reply-To: <CAD33W0y1cxtnrdaA-cYb_PWC3Mz+NoMWTkKgkrfm41FAOLaj8w@mail.gmail.com>
References: <CAD33W0y1cxtnrdaA-cYb_PWC3Mz+NoMWTkKgkrfm41FAOLaj8w@mail.gmail.com>
Message-ID: <20181010012902.wwh4cype6llkfli3@yuggoth.org>

On 2018-10-10 02:54:52 +0200 (+0200), Jay See wrote:
> May be a different question , not completely related to issues
> associated with openstack.
> 
> Does anyone know any university or universities using opnstack for
> cloud deployment and resource sharing.

There are many, but the first which comes to mind for me is the
Massachusetts Institute of Technology:

    https://tig.csail.mit.edu/shared-computing/open-stack/

-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181010/5a17cdfe/attachment.sig>

From davanum at gmail.com  Wed Oct 10 02:07:35 2018
From: davanum at gmail.com (Davanum Srinivas)
Date: Tue, 9 Oct 2018 22:07:35 -0400
Subject: [Openstack] [openstack] openstack setups at Universities
In-Reply-To: <20181010012902.wwh4cype6llkfli3@yuggoth.org>
References: <CAD33W0y1cxtnrdaA-cYb_PWC3Mz+NoMWTkKgkrfm41FAOLaj8w@mail.gmail.com>
 <20181010012902.wwh4cype6llkfli3@yuggoth.org>
Message-ID: <CANw6fcETS4+DcquU7kRXeShcX8edUUL9mVqXu6A2v_8dNKB1Wg@mail.gmail.com>

BU + North Eastern - https://massopen.cloud/blog/moc-production-kaizen/


On Tue, Oct 9, 2018 at 9:41 PM Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2018-10-10 02:54:52 +0200 (+0200), Jay See wrote:
> > May be a different question , not completely related to issues
> > associated with openstack.
> >
> > Does anyone know any university or universities using opnstack for
> > cloud deployment and resource sharing.
>
> There are many, but the first which comes to mind for me is the
> Massachusetts Institute of Technology:
>
>     https://tig.csail.mit.edu/shared-computing/open-stack/
>
> --
> Jeremy Stanley
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>


-- 
Davanum Srinivas :: https://twitter.com/dims
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181009/f3021bd3/attachment.html>

From adhi.pri at gmail.com  Thu Oct 11 06:14:16 2018
From: adhi.pri at gmail.com (Adhi Priharmanto)
Date: Thu, 11 Oct 2018 13:14:16 +0700
Subject: [Openstack] [nova][ceph] Libvirt Error when add ceph as nova backend
Message-ID: <CAHaOoEU3kjHh0hXDUQrDiVd-A8SjHdKSgk9kBfFeHu4fq4OKFQ@mail.gmail.com>

Hi, Im running my openstack environment with rocky release, and I want to
integrate ceph as nova-compute backend, so I followed instruction here :
http://superuser.openstack.org/articl...
<http://superuser.openstack.org/articles/ceph-as-storage-for-openstack/>

and this is my nova.conf at my compute node

[DEFAULT]
...
compute_driver=libvirt.LibvirtDriver

[libvirt]
images_type = rbd
images_rbd_pool = vms
images_rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_user = nova
rbd_secret_uuid = a93824e0-2d45-4196-8918-c8f7d7f35c5d
....

and this is log when I restarted the nova compute service :

2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
[req-f4e2715a-c925-4c12-b8e6-aa550fc588b1 - - - - -] Exception
handling connection event: AttributeError: 'NoneType' object has no
attribute 'rfind'
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host Traceback
(most recent call last):
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line
148, in _dispatch_conn_event
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     handler()
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line
414, in handler
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     return
self._conn_event_handler(*args, **kwargs)
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
470, in _handle_conn_event
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
self._set_host_enabled(enabled, reason)
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
3780, in _set_host_enabled
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
mount.get_manager().host_up(self._host)
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/mount.py",
line 134, in host_up
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
self.state = _HostMountState(host, self.generation)
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/mount.py",
line 229, in __init__
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
mountpoint = os.path.dirname(disk.source_path)
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
"/usr/lib64/python2.7/posixpath.py", line 129, in dirname
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     i =
p.rfind('/') + 1
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
AttributeError: 'NoneType' object has no attribute 'rfind'
2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
2018-10-11 01:59:57.231 5275 WARNING nova.compute.monitors
[req-df2559f3-5a01-499a-9ac0-3dd9dc255f77 - - - - -] Excluding
nova.compute.monitors.cpu monitor virt_driver. Not in the list of
enabled monitors (CONF.compute_monitors).
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
[req-df2559f3-5a01-499a-9ac0-3dd9dc255f77 - - - - -] Error updating
resources for node cp2.os-srg.adhi.: TimedOut: [errno 110] error
connecting to the cluster
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager Traceback
(most recent call last):
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 7722,
in _update_available_resource_for_node
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
rt.update_available_resource(context, nodename)
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
"/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py",
line 687, in update_available_resource
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     resources
= self.driver.get_available_resource(nodename)
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
6505, in get_available_resource
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
disk_info_dict = self._get_local_gb_info()
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
5704, in _get_local_gb_info
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     info =
LibvirtDriver._get_rbd_driver().get_pool_info()
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
line 368, in get_pool_info
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     with
RADOSClient(self) as client:
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
line 102, in __init__
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
self.cluster, self.ioctx = driver._connect_to_rados(pool)
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
line 133, in _connect_to_rados
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     client.connect()
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
"rados.pyx", line 875, in rados.Rados.connect
(/builddir/build/BUILD/ceph-12.2.5/build/src/pybind/rados/pyrex/rados.c:9764)
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager TimedOut:
[errno 110] error connecting to the cluster
2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
2018-10-11 02:04:57.316 5275 ERROR oslo.messaging._drivers.impl_rabbit
[-] [bc957cdf-01b6-4d9a-8cb2-87f880f67cf9] AMQP server on
ct.os-srg.adhi:5672 is unreachable: [Errno 104] Connection reset by
peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset
by peer
2018-10-11 02:04:58.353 5275 INFO oslo.messaging._drivers.impl_rabbit
[-] [bc957cdf-01b6-4d9a-8cb2-87f880f67cf9] Reconnected to AMQP server
on ct.os-srg.adhi:5672 via [amqp] client with port 60704.
2018-10-11 02:05:02.347 5275 ERROR oslo.messaging._drivers.impl_rabbit
[-] [2dda91e7-c913-4203-a198-ca53f231dfdc] AMQP server on
ct.os-srg.adhi:5672 is unreachable: [Errno 104] Connection reset by
peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset
by peer
2018-10-11 02:05:03.376 5275 INFO oslo.messaging._drivers.impl_rabbit
[-] [2dda91e7-c913-4203-a198-ca53f231dfdc] Reconnected to AMQP server
on ct.os-srg.adhi:5672 via [amqp] client with port 60706.

does anyone can help me with this problem ?

-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi
<http://about.me/a_dhi?promo=email_sig>
+62-812-82121584
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181011/ccdf598c/attachment.html>

From eblock at nde.ag  Thu Oct 11 07:09:34 2018
From: eblock at nde.ag (Eugen Block)
Date: Thu, 11 Oct 2018 07:09:34 +0000
Subject: [Openstack] [nova][ceph] Libvirt Error when add ceph as nova
 backend
In-Reply-To: <CAHaOoEU3kjHh0hXDUQrDiVd-A8SjHdKSgk9kBfFeHu4fq4OKFQ@mail.gmail.com>
Message-ID: <20181011070934.Horde.wqdrJxUy1so2cD8_xoQiinj@webmail.nde.ag>

Hi,

your nova.conf [libvirt] section seems fine.

Can you paste the output of

ceph auth get client.nova

and does the keyring file exist in /etc/ceph/ (ceph.client.nova.keyring)?

Is the ceph network reachable by your openstack nodes?

Regards,
Eugen


Zitat von Adhi Priharmanto <adhi.pri at gmail.com>:

> Hi, Im running my openstack environment with rocky release, and I want to
> integrate ceph as nova-compute backend, so I followed instruction here :
> http://superuser.openstack.org/articl...
> <http://superuser.openstack.org/articles/ceph-as-storage-for-openstack/>
>
> and this is my nova.conf at my compute node
>
> [DEFAULT]
> ...
> compute_driver=libvirt.LibvirtDriver
>
> [libvirt]
> images_type = rbd
> images_rbd_pool = vms
> images_rbd_ceph_conf = /etc/ceph/ceph.conf
> rbd_user = nova
> rbd_secret_uuid = a93824e0-2d45-4196-8918-c8f7d7f35c5d
> ....
>
> and this is log when I restarted the nova compute service :
>
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> [req-f4e2715a-c925-4c12-b8e6-aa550fc588b1 - - - - -] Exception
> handling connection event: AttributeError: 'NoneType' object has no
> attribute 'rfind'
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host Traceback
> (most recent call last):
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line
> 148, in _dispatch_conn_event
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     handler()
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line
> 414, in handler
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     return
> self._conn_event_handler(*args, **kwargs)
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> 470, in _handle_conn_event
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> self._set_host_enabled(enabled, reason)
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> 3780, in _set_host_enabled
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> mount.get_manager().host_up(self._host)
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/mount.py",
> line 134, in host_up
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> self.state = _HostMountState(host, self.generation)
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/mount.py",
> line 229, in __init__
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> mountpoint = os.path.dirname(disk.source_path)
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> "/usr/lib64/python2.7/posixpath.py", line 129, in dirname
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     i =
> p.rfind('/') + 1
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> AttributeError: 'NoneType' object has no attribute 'rfind'
> 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> 2018-10-11 01:59:57.231 5275 WARNING nova.compute.monitors
> [req-df2559f3-5a01-499a-9ac0-3dd9dc255f77 - - - - -] Excluding
> nova.compute.monitors.cpu monitor virt_driver. Not in the list of
> enabled monitors (CONF.compute_monitors).
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
> [req-df2559f3-5a01-499a-9ac0-3dd9dc255f77 - - - - -] Error updating
> resources for node cp2.os-srg.adhi.: TimedOut: [errno 110] error
> connecting to the cluster
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager Traceback
> (most recent call last):
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 7722,
> in _update_available_resource_for_node
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
> rt.update_available_resource(context, nodename)
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> "/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py",
> line 687, in update_available_resource
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     resources
> = self.driver.get_available_resource(nodename)
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> 6505, in get_available_resource
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
> disk_info_dict = self._get_local_gb_info()
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> 5704, in _get_local_gb_info
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     info =
> LibvirtDriver._get_rbd_driver().get_pool_info()
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
> line 368, in get_pool_info
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     with
> RADOSClient(self) as client:
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
> line 102, in __init__
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
> self.cluster, self.ioctx = driver._connect_to_rados(pool)
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
> line 133, in _connect_to_rados
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     client.connect()
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> "rados.pyx", line 875, in rados.Rados.connect
> (/builddir/build/BUILD/ceph-12.2.5/build/src/pybind/rados/pyrex/rados.c:9764)
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager TimedOut:
> [errno 110] error connecting to the cluster
> 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
> 2018-10-11 02:04:57.316 5275 ERROR oslo.messaging._drivers.impl_rabbit
> [-] [bc957cdf-01b6-4d9a-8cb2-87f880f67cf9] AMQP server on
> ct.os-srg.adhi:5672 is unreachable: [Errno 104] Connection reset by
> peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset
> by peer
> 2018-10-11 02:04:58.353 5275 INFO oslo.messaging._drivers.impl_rabbit
> [-] [bc957cdf-01b6-4d9a-8cb2-87f880f67cf9] Reconnected to AMQP server
> on ct.os-srg.adhi:5672 via [amqp] client with port 60704.
> 2018-10-11 02:05:02.347 5275 ERROR oslo.messaging._drivers.impl_rabbit
> [-] [2dda91e7-c913-4203-a198-ca53f231dfdc] AMQP server on
> ct.os-srg.adhi:5672 is unreachable: [Errno 104] Connection reset by
> peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset
> by peer
> 2018-10-11 02:05:03.376 5275 INFO oslo.messaging._drivers.impl_rabbit
> [-] [2dda91e7-c913-4203-a198-ca53f231dfdc] Reconnected to AMQP server
> on ct.os-srg.adhi:5672 via [amqp] client with port 60706.
>
> does anyone can help me with this problem ?
>
> --
> Cheers,
>
>
>
> [image: --]
> Adhi Priharmanto
> [image: http://]about.me/a_dhi
> <http://about.me/a_dhi?promo=email_sig>
> +62-812-82121584





From jim at jokken.com  Thu Oct 11 20:08:47 2018
From: jim at jokken.com (Jim Okken)
Date: Thu, 11 Oct 2018 16:08:47 -0400
Subject: [Openstack] [Cinder] HP MSA array as a secondary backend is
 only used user is an admin
Message-ID: <CAMG=QuoGOS02+nXdmUJpXDT5w5Wdch_tcaRrNnEAj0sNtu+Qog@mail.gmail.com>

hi All,

not sure if I can find an answer here to this specific situation with the
cinder backend driver cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver.
If not how can I get in touch with someone more familiar with
cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver

we have a HP MSA storage array connected to most of our compute nodes and
we are using the cinder driver
cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver as a second backend so
that openstack can, if directed by metadata, create volumes on it during
instance creation. Openstack creates volumes using this MSA backend if the
metadata of the image selected contains "cinder_image_volume_type=MSA".
This second MSA type of volume was added to cinder.

We use a CentOS-6-x86_64-GenericCloud-1707.qcow2 image which has this
metadata added. Without this metadata RBD/CEPH images are made

This works great for the admin user but not for a regular _ member_ user.

With the admin user volumes created show Type=*MSA* and
Host=node-44.domain.com@*MSA#A*. (correct)

With the _member_ user volumes created show Type=*MSA* but
Host=rbd:volumes at RBD-backend#*RBD-backend (this is CEPH, incorrect!)*.

And I can confirm the volume is not on the MSA. Correct RBD/CEPH volumes
show Type=*volumes_ceph* and Host=rbd:volumes at RBD-backend#*RBD-backend*.

This happens if the cinder volume type is created as a Private type or a
Public type.

I have tried to set the properties on the cinder MSA volume type for the
specific project we want to use this volume type in, and to set the
project-domain for this volume type. nothing has helped.

can anyone shed any light on this behavior or point out anything helpful in
the logs pls?

Looking at the logs I do see the _ member_ user is a non-default-domain
user while admin is obviously the default domain. other than that I can't
make heads or tails of the logs.

Here are logs if anyone wants to look at them:
a bad _ member_ volume creation was UUID
fb9047c3-1b6b-4d2b-bae8-5177e86eb1f2 https://pastebin.com/bmFAy6RR

a good admin volume creation was UUID b49e33db-8ab8-489f-b7cb-092f421178c1
https://pastebin.com/5SAecNJ2

We are using Newton, thanks!!!


-- Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181011/579a03e2/attachment.html>

From adhi.pri at gmail.com  Fri Oct 12 03:53:22 2018
From: adhi.pri at gmail.com (Adhi Priharmanto)
Date: Fri, 12 Oct 2018 10:53:22 +0700
Subject: [Openstack] [nova][ceph] Libvirt Error when add ceph as nova
	backend
In-Reply-To: <20181011070934.Horde.wqdrJxUy1so2cD8_xoQiinj@webmail.nde.ag>
References: <CAHaOoEU3kjHh0hXDUQrDiVd-A8SjHdKSgk9kBfFeHu4fq4OKFQ@mail.gmail.com>
 <20181011070934.Horde.wqdrJxUy1so2cD8_xoQiinj@webmail.nde.ag>
Message-ID: <CAHaOoEU20cGdd9OX0mMmA9Jstu=9m=JRLkJafRe63yYm582H-A@mail.gmail.com>

Hi,
This is my ceph node ( using single node ceph) for test only

> [cephdeploy at ceph2 ~]$ cat /etc/ceph/ceph.client.nova.keyring
> [client.nova]
> key = AQBLxr5bbhnGFxAAXAliVJwMU5w5YgFY6jGJIA==
> [cephdeploy at ceph2 ~]$ ceph auth get client.nova
> exported keyring for client.nova
> [client.nova]
> key = AQBLxr5bbhnGFxAAXAliVJwMU5w5YgFY6jGJIA==
> caps mon = "allow r"
> caps osd = "allow class-read object_prefix rbd_children, allow rwx
> pool=vms, allow rx pool=images"
> [cephdeploy at ceph2 ~]$


and this at my compute-node

> [root at cp2 ~]# cat /etc/ceph/ceph.client.nova.keyring
> [client.nova]
> key = AQBLxr5bbhnGFxAAXAliVJwMU5w5YgFY6jGJIA==
> [root at cp2 ~]#

yes both nodes, ceph & nova-compute node was on same network
192.168.26.xx/24 , does any special port need to allow at firewalld ?

On Thu, Oct 11, 2018 at 2:24 PM Eugen Block <eblock at nde.ag> wrote:

> Hi,
>
> your nova.conf [libvirt] section seems fine.
>
> Can you paste the output of
>
> ceph auth get client.nova
>
> and does the keyring file exist in /etc/ceph/ (ceph.client.nova.keyring)?
>
> Is the ceph network reachable by your openstack nodes?
>
> Regards,
> Eugen
>
>
> Zitat von Adhi Priharmanto <adhi.pri at gmail.com>:
>
> > Hi, Im running my openstack environment with rocky release, and I want to
> > integrate ceph as nova-compute backend, so I followed instruction here :
> > http://superuser.openstack.org/articl...
> > <http://superuser.openstack.org/articles/ceph-as-storage-for-openstack/>
> >
> > and this is my nova.conf at my compute node
> >
> > [DEFAULT]
> > ...
> > compute_driver=libvirt.LibvirtDriver
> >
> > [libvirt]
> > images_type = rbd
> > images_rbd_pool = vms
> > images_rbd_ceph_conf = /etc/ceph/ceph.conf
> > rbd_user = nova
> > rbd_secret_uuid = a93824e0-2d45-4196-8918-c8f7d7f35c5d
> > ....
> >
> > and this is log when I restarted the nova compute service :
> >
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> > [req-f4e2715a-c925-4c12-b8e6-aa550fc588b1 - - - - -] Exception
> > handling connection event: AttributeError: 'NoneType' object has no
> > attribute 'rfind'
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host Traceback
> > (most recent call last):
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line
> > 148, in _dispatch_conn_event
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     handler()
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line
> > 414, in handler
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     return
> > self._conn_event_handler(*args, **kwargs)
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> > 470, in _handle_conn_event
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> > self._set_host_enabled(enabled, reason)
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> > 3780, in _set_host_enabled
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> > mount.get_manager().host_up(self._host)
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/mount.py",
> > line 134, in host_up
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> > self.state = _HostMountState(host, self.generation)
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/mount.py",
> > line 229, in __init__
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> > mountpoint = os.path.dirname(disk.source_path)
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
> > "/usr/lib64/python2.7/posixpath.py", line 129, in dirname
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     i =
> > p.rfind('/') + 1
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> > AttributeError: 'NoneType' object has no attribute 'rfind'
> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
> > 2018-10-11 01:59:57.231 5275 WARNING nova.compute.monitors
> > [req-df2559f3-5a01-499a-9ac0-3dd9dc255f77 - - - - -] Excluding
> > nova.compute.monitors.cpu monitor virt_driver. Not in the list of
> > enabled monitors (CONF.compute_monitors).
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
> > [req-df2559f3-5a01-499a-9ac0-3dd9dc255f77 - - - - -] Error updating
> > resources for node cp2.os-srg.adhi.: TimedOut: [errno 110] error
> > connecting to the cluster
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager Traceback
> > (most recent call last):
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> > "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 7722,
> > in _update_available_resource_for_node
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
> > rt.update_available_resource(context, nodename)
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> > "/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py",
> > line 687, in update_available_resource
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     resources
> > = self.driver.get_available_resource(nodename)
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> > 6505, in get_available_resource
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
> > disk_info_dict = self._get_local_gb_info()
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> > 5704, in _get_local_gb_info
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     info =
> > LibvirtDriver._get_rbd_driver().get_pool_info()
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> >
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
> > line 368, in get_pool_info
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     with
> > RADOSClient(self) as client:
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> >
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
> > line 102, in __init__
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
> > self.cluster, self.ioctx = driver._connect_to_rados(pool)
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> >
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
> > line 133, in _connect_to_rados
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
>  client.connect()
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
> > "rados.pyx", line 875, in rados.Rados.connect
> >
> (/builddir/build/BUILD/ceph-12.2.5/build/src/pybind/rados/pyrex/rados.c:9764)
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager TimedOut:
> > [errno 110] error connecting to the cluster
> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
> > 2018-10-11 02:04:57.316 5275 ERROR oslo.messaging._drivers.impl_rabbit
> > [-] [bc957cdf-01b6-4d9a-8cb2-87f880f67cf9] AMQP server on
> > ct.os-srg.adhi:5672 is unreachable: [Errno 104] Connection reset by
> > peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset
> > by peer
> > 2018-10-11 02:04:58.353 5275 INFO oslo.messaging._drivers.impl_rabbit
> > [-] [bc957cdf-01b6-4d9a-8cb2-87f880f67cf9] Reconnected to AMQP server
> > on ct.os-srg.adhi:5672 via [amqp] client with port 60704.
> > 2018-10-11 02:05:02.347 5275 ERROR oslo.messaging._drivers.impl_rabbit
> > [-] [2dda91e7-c913-4203-a198-ca53f231dfdc] AMQP server on
> > ct.os-srg.adhi:5672 is unreachable: [Errno 104] Connection reset by
> > peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset
> > by peer
> > 2018-10-11 02:05:03.376 5275 INFO oslo.messaging._drivers.impl_rabbit
> > [-] [2dda91e7-c913-4203-a198-ca53f231dfdc] Reconnected to AMQP server
> > on ct.os-srg.adhi:5672 via [amqp] client with port 60706.
> >
> > does anyone can help me with this problem ?
> >
> > --
> > Cheers,
> >
> >
> >
> > [image: --]
> > Adhi Priharmanto
> > [image: http://]about.me/a_dhi
> > <http://about.me/a_dhi?promo=email_sig>
> > +62-812-82121584
>
>
>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>


-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi
<http://about.me/a_dhi?promo=email_sig>
+62-812-82121584
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181012/f227f90b/attachment.html>

From eblock at nde.ag  Fri Oct 12 08:31:50 2018
From: eblock at nde.ag (Eugen Block)
Date: Fri, 12 Oct 2018 08:31:50 +0000
Subject: [Openstack] [nova][ceph] Libvirt Error when add ceph as nova
 backend
In-Reply-To: <CAHaOoEU20cGdd9OX0mMmA9Jstu=9m=JRLkJafRe63yYm582H-A@mail.gmail.com>
References: <CAHaOoEU3kjHh0hXDUQrDiVd-A8SjHdKSgk9kBfFeHu4fq4OKFQ@mail.gmail.com>
 <20181011070934.Horde.wqdrJxUy1so2cD8_xoQiinj@webmail.nde.ag>
 <CAHaOoEU20cGdd9OX0mMmA9Jstu=9m=JRLkJafRe63yYm582H-A@mail.gmail.com>
Message-ID: <20181012083150.Horde.7hT3eJFCtKHdvWD-XIQITpb@webmail.nde.ag>

Hi,

the keyrings and caps seem correct to me.

> yes both nodes, ceph & nova-compute node was on same network
> 192.168.26.xx/24 , does any special port need to allow at firewalld ?

Yes, the firewall should allow the traffic between the nodes. If this  
is just a test environment you could try disabling the firewall. If  
this is not an option, open the respective ports, an excerpt from the  
docs:

> For iptables, add port 6789 for Ceph Monitors and ports 6800:7300  
> for Ceph OSDs.

For more information take a look into [1]. Can you see requests  
blocked in your firewall?

Regards,
Eugen

[1] http://docs.ceph.com/docs/master/start/quick-start-preflight/


Zitat von Adhi Priharmanto <adhi.pri at gmail.com>:

> Hi,
> This is my ceph node ( using single node ceph) for test only
>
>> [cephdeploy at ceph2 ~]$ cat /etc/ceph/ceph.client.nova.keyring
>> [client.nova]
>> key = AQBLxr5bbhnGFxAAXAliVJwMU5w5YgFY6jGJIA==
>> [cephdeploy at ceph2 ~]$ ceph auth get client.nova
>> exported keyring for client.nova
>> [client.nova]
>> key = AQBLxr5bbhnGFxAAXAliVJwMU5w5YgFY6jGJIA==
>> caps mon = "allow r"
>> caps osd = "allow class-read object_prefix rbd_children, allow rwx
>> pool=vms, allow rx pool=images"
>> [cephdeploy at ceph2 ~]$
>
>
> and this at my compute-node
>
>> [root at cp2 ~]# cat /etc/ceph/ceph.client.nova.keyring
>> [client.nova]
>> key = AQBLxr5bbhnGFxAAXAliVJwMU5w5YgFY6jGJIA==
>> [root at cp2 ~]#
>
> yes both nodes, ceph & nova-compute node was on same network
> 192.168.26.xx/24 , does any special port need to allow at firewalld ?
>
> On Thu, Oct 11, 2018 at 2:24 PM Eugen Block <eblock at nde.ag> wrote:
>
>> Hi,
>>
>> your nova.conf [libvirt] section seems fine.
>>
>> Can you paste the output of
>>
>> ceph auth get client.nova
>>
>> and does the keyring file exist in /etc/ceph/ (ceph.client.nova.keyring)?
>>
>> Is the ceph network reachable by your openstack nodes?
>>
>> Regards,
>> Eugen
>>
>>
>> Zitat von Adhi Priharmanto <adhi.pri at gmail.com>:
>>
>> > Hi, Im running my openstack environment with rocky release, and I want to
>> > integrate ceph as nova-compute backend, so I followed instruction here :
>> > http://superuser.openstack.org/articl...
>> > <http://superuser.openstack.org/articles/ceph-as-storage-for-openstack/>
>> >
>> > and this is my nova.conf at my compute node
>> >
>> > [DEFAULT]
>> > ...
>> > compute_driver=libvirt.LibvirtDriver
>> >
>> > [libvirt]
>> > images_type = rbd
>> > images_rbd_pool = vms
>> > images_rbd_ceph_conf = /etc/ceph/ceph.conf
>> > rbd_user = nova
>> > rbd_secret_uuid = a93824e0-2d45-4196-8918-c8f7d7f35c5d
>> > ....
>> >
>> > and this is log when I restarted the nova compute service :
>> >
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
>> > [req-f4e2715a-c925-4c12-b8e6-aa550fc588b1 - - - - -] Exception
>> > handling connection event: AttributeError: 'NoneType' object has no
>> > attribute 'rfind'
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host Traceback
>> > (most recent call last):
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line
>> > 148, in _dispatch_conn_event
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     handler()
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line
>> > 414, in handler
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     return
>> > self._conn_event_handler(*args, **kwargs)
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
>> > 470, in _handle_conn_event
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
>> > self._set_host_enabled(enabled, reason)
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
>> > 3780, in _set_host_enabled
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
>> > mount.get_manager().host_up(self._host)
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/mount.py",
>> > line 134, in host_up
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
>> > self.state = _HostMountState(host, self.generation)
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/volume/mount.py",
>> > line 229, in __init__
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
>> > mountpoint = os.path.dirname(disk.source_path)
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host   File
>> > "/usr/lib64/python2.7/posixpath.py", line 129, in dirname
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host     i =
>> > p.rfind('/') + 1
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
>> > AttributeError: 'NoneType' object has no attribute 'rfind'
>> > 2018-10-11 01:59:57.123 5275 ERROR nova.virt.libvirt.host
>> > 2018-10-11 01:59:57.231 5275 WARNING nova.compute.monitors
>> > [req-df2559f3-5a01-499a-9ac0-3dd9dc255f77 - - - - -] Excluding
>> > nova.compute.monitors.cpu monitor virt_driver. Not in the list of
>> > enabled monitors (CONF.compute_monitors).
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
>> > [req-df2559f3-5a01-499a-9ac0-3dd9dc255f77 - - - - -] Error updating
>> > resources for node cp2.os-srg.adhi.: TimedOut: [errno 110] error
>> > connecting to the cluster
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager Traceback
>> > (most recent call last):
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
>> > "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 7722,
>> > in _update_available_resource_for_node
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
>> > rt.update_available_resource(context, nodename)
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
>> > "/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py",
>> > line 687, in update_available_resource
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     resources
>> > = self.driver.get_available_resource(nodename)
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
>> > 6505, in get_available_resource
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
>> > disk_info_dict = self._get_local_gb_info()
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
>> > 5704, in _get_local_gb_info
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     info =
>> > LibvirtDriver._get_rbd_driver().get_pool_info()
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
>> >
>> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
>> > line 368, in get_pool_info
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager     with
>> > RADOSClient(self) as client:
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
>> >
>> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
>> > line 102, in __init__
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
>> > self.cluster, self.ioctx = driver._connect_to_rados(pool)
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
>> >
>> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py",
>> > line 133, in _connect_to_rados
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
>>  client.connect()
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager   File
>> > "rados.pyx", line 875, in rados.Rados.connect
>> >
>> (/builddir/build/BUILD/ceph-12.2.5/build/src/pybind/rados/pyrex/rados.c:9764)
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager TimedOut:
>> > [errno 110] error connecting to the cluster
>> > 2018-10-11 02:04:57.279 5275 ERROR nova.compute.manager
>> > 2018-10-11 02:04:57.316 5275 ERROR oslo.messaging._drivers.impl_rabbit
>> > [-] [bc957cdf-01b6-4d9a-8cb2-87f880f67cf9] AMQP server on
>> > ct.os-srg.adhi:5672 is unreachable: [Errno 104] Connection reset by
>> > peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset
>> > by peer
>> > 2018-10-11 02:04:58.353 5275 INFO oslo.messaging._drivers.impl_rabbit
>> > [-] [bc957cdf-01b6-4d9a-8cb2-87f880f67cf9] Reconnected to AMQP server
>> > on ct.os-srg.adhi:5672 via [amqp] client with port 60704.
>> > 2018-10-11 02:05:02.347 5275 ERROR oslo.messaging._drivers.impl_rabbit
>> > [-] [2dda91e7-c913-4203-a198-ca53f231dfdc] AMQP server on
>> > ct.os-srg.adhi:5672 is unreachable: [Errno 104] Connection reset by
>> > peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset
>> > by peer
>> > 2018-10-11 02:05:03.376 5275 INFO oslo.messaging._drivers.impl_rabbit
>> > [-] [2dda91e7-c913-4203-a198-ca53f231dfdc] Reconnected to AMQP server
>> > on ct.os-srg.adhi:5672 via [amqp] client with port 60706.
>> >
>> > does anyone can help me with this problem ?
>> >
>> > --
>> > Cheers,
>> >
>> >
>> >
>> > [image: --]
>> > Adhi Priharmanto
>> > [image: http://]about.me/a_dhi
>> > <http://about.me/a_dhi?promo=email_sig>
>> > +62-812-82121584
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
>
> --
> Cheers,
>
>
>
> [image: --]
> Adhi Priharmanto
> [image: http://]about.me/a_dhi
> <http://about.me/a_dhi?promo=email_sig>
> +62-812-82121584





From matthias.leopold at meduniwien.ac.at  Fri Oct 12 12:21:24 2018
From: matthias.leopold at meduniwien.ac.at (Matthias Leopold)
Date: Fri, 12 Oct 2018 14:21:24 +0200
Subject: [Openstack] Pike: cinderclient noauth problem
Message-ID: <815bee71-ebac-5331-e147-405eec3bdc06@meduniwien.ac.at>

Hi,

my standalone Pike Cinder installation works perfectly with 
"auth_strategy = keystone" and i can use cinderclient CLI to interact 
with it.

Now i want to temporarily test it with "auth_strategy = noauth".
I followed 
https://docs.openstack.org/python-cinderclient/pike/user/no_auth.html, 
but when i execute "cinder list" i am still asked for "OS Password:". Why?

Cinder binaries are from Centos 7 "centos-openstack-pike" repository.
# rpm -q python2-cinderclient
python2-cinderclient-3.1.0-1.el7.noarch

thx
matthias


From e0ne at e0ne.info  Fri Oct 12 13:48:48 2018
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Fri, 12 Oct 2018 16:48:48 +0300
Subject: [Openstack] Pike: cinderclient noauth problem
In-Reply-To: <815bee71-ebac-5331-e147-405eec3bdc06@meduniwien.ac.at>
References: <815bee71-ebac-5331-e147-405eec3bdc06@meduniwien.ac.at>
Message-ID: <CAGocpaGxGJnT1Z8oQ9Dc+LO9mygegHDS4KLqWGXVRcwzhwynyQ@mail.gmail.com>

Hi Matthias,

Did you try to use OS_AUTH_TYPE=noauth environment variable or add
'--os-auth-type=noauth' option to the cinderclient?

auth_strategy option should be set in cinder.con for API access too


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Fri, Oct 12, 2018 at 3:32 PM Matthias Leopold <
matthias.leopold at meduniwien.ac.at> wrote:

> Hi,
>
> my standalone Pike Cinder installation works perfectly with
> "auth_strategy = keystone" and i can use cinderclient CLI to interact
> with it.
>
> Now i want to temporarily test it with "auth_strategy = noauth".
> I followed
> https://docs.openstack.org/python-cinderclient/pike/user/no_auth.html,
> but when i execute "cinder list" i am still asked for "OS Password:". Why?
>
> Cinder binaries are from Centos 7 "centos-openstack-pike" repository.
> # rpm -q python2-cinderclient
> python2-cinderclient-3.1.0-1.el7.noarch
>
> thx
> matthias
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181012/75b9f4af/attachment.html>

From matthias.leopold at meduniwien.ac.at  Fri Oct 12 14:18:24 2018
From: matthias.leopold at meduniwien.ac.at (Matthias Leopold)
Date: Fri, 12 Oct 2018 16:18:24 +0200
Subject: [Openstack] Pike: cinderclient noauth problem
In-Reply-To: <CAGocpaGxGJnT1Z8oQ9Dc+LO9mygegHDS4KLqWGXVRcwzhwynyQ@mail.gmail.com>
References: <815bee71-ebac-5331-e147-405eec3bdc06@meduniwien.ac.at>
 <CAGocpaGxGJnT1Z8oQ9Dc+LO9mygegHDS4KLqWGXVRcwzhwynyQ@mail.gmail.com>
Message-ID: <1d79ba90-c380-1f9f-6249-1b331ead0c52@meduniwien.ac.at>

I stuck to the example from 
https://docs.openstack.org/python-cinderclient/pike/user/no_auth.html, 
which uses OS_AUTH_TYPE=noauth environment variable

also, auth_strategy=noauth is set in cinder.conf

matthias

Am 2018-10-12 um 15:48 schrieb Ivan Kolodyazhny:
> Hi Matthias,
> 
> Did you try to use OS_AUTH_TYPE=noauth environment variable or add 
> '--os-auth-type=noauth' option to the cinderclient?
> 
> auth_strategy option should be set in cinder.con for API access too
> 
> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> 
> 
> On Fri, Oct 12, 2018 at 3:32 PM Matthias Leopold 
> <matthias.leopold at meduniwien.ac.at 
> <mailto:matthias.leopold at meduniwien.ac.at>> wrote:
> 
>     Hi,
> 
>     my standalone Pike Cinder installation works perfectly with
>     "auth_strategy = keystone" and i can use cinderclient CLI to interact
>     with it.
> 
>     Now i want to temporarily test it with "auth_strategy = noauth".
>     I followed
>     https://docs.openstack.org/python-cinderclient/pike/user/no_auth.html,
>     but when i execute "cinder list" i am still asked for "OS
>     Password:". Why?
> 
>     Cinder binaries are from Centos 7 "centos-openstack-pike" repository.
>     # rpm -q python2-cinderclient
>     python2-cinderclient-3.1.0-1.el7.noarch
> 
>     thx
>     matthias
> 
>     _______________________________________________
>     Mailing list:
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>     Post to     : openstack at lists.openstack.org
>     <mailto:openstack at lists.openstack.org>
>     Unsubscribe :
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 

-- 
Matthias Leopold
IT Systems & Communications
Medizinische Universität Wien
Spitalgasse 23 / BT 88 /Ebene 00
A-1090 Wien
Tel: +43 1 40160-21241
Fax: +43 1 40160-921200


From robert at componentsoft.io  Fri Oct 12 14:35:19 2018
From: robert at componentsoft.io (Robert Varjasi)
Date: Fri, 12 Oct 2018 16:35:19 +0200
Subject: [Openstack] nova-api-os-compute slowdown
In-Reply-To: <c6b6426e-49d9-a7f1-f741-135181a06216@componentsoft.io>
References: <c6b6426e-49d9-a7f1-f741-135181a06216@componentsoft.io>
Message-ID: <915bf691-d741-dd9c-7143-050088b5700b@componentsoft.io>

Hi,

I found that my controller nodes were a bit overloaded with 16 uwsgi
nova-api-os compute processes. I reduced the nova-api-os uwsgi processes
to 10 and timeout and slowdowns were eliminated. My cloud went stable
and the response times went lower. I have 20 vcpus on a Xeon(R) CPU
E5-2630 v4 @ 2.20GHz.

For the openstack-ansible I need to change this variable from 16 to 10:
nova_wsgi_processes_max: 10. Seems I need to set it to an equal number
of my cpu cores.

Regards,
Robert Varjasi
consultant at Component Soft Ltd.
Tel: +36/30-259-9221

On 10/08/2018 06:33 PM, Robert Varjasi wrote:
> Hi,
>
> After a few tempest run I noticed slowdowns in the nova-api-os-compute
> uwsgi  processes. I check the processes with py-spy and found that a lot
> of process blocked on read(). Here is my py-spy output from one of my
> nova-api-os-compute uwsgi process: http://paste.openstack.org/show/731677/
>
> And the stack trace:
>
> thread_id = Thread-2 filename = /usr/lib/python2.7/threading.py lineno =
> 774 function = __bootstrap line = self.__bootstrap_inner()
> thread_id = Thread-2 filename = /usr/lib/python2.7/threading.py lineno =
> 801 function = __bootstrap_inner line = self.run()
> thread_id = Thread-2 filename = /usr/lib/python2.7/threading.py lineno =
> 754 function = run line = self.__target(*self.__args, **self.__kwargs)
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py
> lineno = 382 function = poll line =
> self.conn.consume(timeout=current_timeout)
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
> lineno = 1083 function = consume line = error_callback=_error_callback)
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
> lineno = 807 function = ensure line = ret, channel = autoretry_method()
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/connection.py
> lineno = 494 function = _ensured line = return fun(*args, **kwargs)
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/connection.py
> lineno = 570 function = __call__ line = return fun(*args,
> channel=channels[0], **kwargs), channels[0]
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
> lineno = 796 function = execute_method line = method()
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
> lineno = 1068 function = _consume line =
> self.connection.drain_events(timeout=poll_timeout)
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/connection.py
> lineno = 301 function = drain_events line = return
> self.transport.drain_events(self.connection, **kwargs)
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/transport/pyamqp.py
> lineno = 103 function = drain_events line = return
> connection.drain_events(**kwargs)
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/connection.py
> lineno = 471 function = drain_events line = while not
> self.blocking_read(timeout):
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/connection.py
> lineno = 476 function = blocking_read line = frame =
> self.transport.read_frame()
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/transport.py
> lineno = 226 function = read_frame line = frame_header = read(7, True)
> thread_id = Thread-2 filename =
> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/transport.py
> lineno = 346 function = _read line = s = recv(n - len(rbuf))  # see note
> above
> thread_id = Thread-2 filename = /usr/lib/python2.7/ssl.py lineno = 643
> function = read line = v = self._sslobj.read(len)
>
> I am using nova 17.0.4.dev1, amqp (2.2.2), oslo.messaging (5.35.0),
> kombu (4.1.0). I have 3 controller nodes. The openstack deployed by OSA
> 17.0.4.
>
> I can reproduce the read() block if I click on "Log" in Horizon to see
> the console outputs from one of my VM or run a tempest test:
> tempest.api.compute.admin.test_hypervisor.HypervisorAdminTestJSON.test_get_hypervisor_uptime.
>
> The nova-api response time increasing when more and more nova-api
> processes get blocked at this read. Is it a normal behavior?
>
> --- 
> Regards,
> Robert Varjasi
> consultant at Component Soft Ltd.
>



From matthias.leopold at meduniwien.ac.at  Fri Oct 12 14:46:10 2018
From: matthias.leopold at meduniwien.ac.at (Matthias Leopold)
Date: Fri, 12 Oct 2018 16:46:10 +0200
Subject: [Openstack] Pike: cinderclient noauth problem
In-Reply-To: <1d79ba90-c380-1f9f-6249-1b331ead0c52@meduniwien.ac.at>
References: <815bee71-ebac-5331-e147-405eec3bdc06@meduniwien.ac.at>
 <CAGocpaGxGJnT1Z8oQ9Dc+LO9mygegHDS4KLqWGXVRcwzhwynyQ@mail.gmail.com>
 <1d79ba90-c380-1f9f-6249-1b331ead0c52@meduniwien.ac.at>
Message-ID: <aa5e46cb-7a11-1776-5571-a5aa5f41308d@meduniwien.ac.at>

OS_AUTH_SYSTEM=noauth seems to work somehow, at least i'm not asked for 
"OS Password:" anymore, now i only get 404 errors...

I'm going to investigate the 404 next week, OS_AUTH_SYSTEM=noauth is 
from cinder-master/contrib/block-box/cinder.rc

matthias

Am 2018-10-12 um 16:18 schrieb Matthias Leopold:
> I stuck to the example from 
> https://docs.openstack.org/python-cinderclient/pike/user/no_auth.html, 
> which uses OS_AUTH_TYPE=noauth environment variable
> 
> also, auth_strategy=noauth is set in cinder.conf
> 
> matthias
> 
> Am 2018-10-12 um 15:48 schrieb Ivan Kolodyazhny:
>> Hi Matthias,
>>
>> Did you try to use OS_AUTH_TYPE=noauth environment variable or add 
>> '--os-auth-type=noauth' option to the cinderclient?
>>
>> auth_strategy option should be set in cinder.con for API access too
>>
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>>
>> On Fri, Oct 12, 2018 at 3:32 PM Matthias Leopold 
>> <matthias.leopold at meduniwien.ac.at 
>> <mailto:matthias.leopold at meduniwien.ac.at>> wrote:
>>
>>     Hi,
>>
>>     my standalone Pike Cinder installation works perfectly with
>>     "auth_strategy = keystone" and i can use cinderclient CLI to interact
>>     with it.
>>
>>     Now i want to temporarily test it with "auth_strategy = noauth".
>>     I followed
>>     
>> https://docs.openstack.org/python-cinderclient/pike/user/no_auth.html,
>>     but when i execute "cinder list" i am still asked for "OS
>>     Password:". Why?
>>
>>     Cinder binaries are from Centos 7 "centos-openstack-pike" repository.
>>     # rpm -q python2-cinderclient
>>     python2-cinderclient-3.1.0-1.el7.noarch
>>
>>     thx
>>     matthias
>>
>>     _______________________________________________
>>     Mailing list:
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>     Post to     : openstack at lists.openstack.org
>>     <mailto:openstack at lists.openstack.org>
>>     Unsubscribe :
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>>
>> _______________________________________________
>> Mailing list: 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
> 

-- 
Matthias Leopold
IT Systems & Communications
Medizinische Universität Wien
Spitalgasse 23 / BT 88 /Ebene 00
A-1090 Wien
Tel: +43 1 40160-21241
Fax: +43 1 40160-921200


From melwittt at gmail.com  Fri Oct 12 17:10:17 2018
From: melwittt at gmail.com (melanie witt)
Date: Fri, 12 Oct 2018 10:10:17 -0700
Subject: [Openstack] [Nova][Glance] Nova imports flat images from base
 file despite ceph backend
In-Reply-To: <20181009080101.Horde.---iO9LIrKkWvTsNJwWk_Mj@webmail.nde.ag>
References: <20180928115051.Horde.ZC_55UzSXeK4hiOjJt6tajA@webmail.nde.ag>
 <A24869C3-C782-48AA-A583-13D435D0356F@enter.eu>
 <20180928125224.Horde.33aqtdk0B9Ncylg-zxjA5to@webmail.nde.ag>
 <9F3C86CE-862D-469A-AD79-3F334CD5DB41@enter.eu>
 <CAHUi5cOtbC9VFaHD0yUeZDF3HqsipLRQ8h43vU-Beqr-ecz3vA@mail.gmail.com>
 <BE4AC4DD-FB62-4C72-ACFA-37E7F5C47CE4@enter.eu>
 <20181004124417.Horde.py2wEG4JmO1oFXbjX5u1uw3@webmail.nde.ag>
 <20181009080101.Horde.---iO9LIrKkWvTsNJwWk_Mj@webmail.nde.ag>
Message-ID: <679352a8-c082-d851-d8a5-ea7b2348b7d3@gmail.com>

On Tue, 09 Oct 2018 08:01:01 +0000, Eugen Block wrote:
> So it's still unclear why nova downloaded a raw glance image to the
> local filesystem during the previous attempt.
> 
> I always knew that with Ceph as backend it's recommended to use raw
> images but I always assumed the "disk-format" was not more than a
> display option. Well, now I know that, but this still doesn't explain
> the downloaded base image.
> If anyone has an idea how to reproduce such behavior or an
> explanation, I'd love to hear it.

Right, in order to get the ceph CoW behavior, you must use RAW glance 
image format [1]. You also need to have created the image as 'raw' 
before you upload to glance (qemu-img info should show the file format 
as 'raw').

If you have done this, then you shouldn't see any image downloaded to 
the local filesystem. Is it possible that your image did not have file 
format 'raw' before you uploaded it to glance?

Cheers,
-melanie

[1] http://docs.ceph.com/docs/master/rbd/rbd-openstack





From torin.woltjer at granddial.com  Fri Oct 12 18:11:18 2018
From: torin.woltjer at granddial.com (Torin Woltjer)
Date: Fri, 12 Oct 2018 18:11:18 GMT
Subject: [Openstack] Rename Cinder Volume
Message-ID: <66bcec61439b4432805bf25ac470e7af@granddial.com>

Is it possible to change the name and description of a Cinder volume? 

Torin Woltjer
 
Grand Dial Communications - A ZK Tech Inc. Company
 
616.776.1066 ext. 2006
www.granddial.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181012/8b995e3a/attachment.html>

From amy at demarco.com  Fri Oct 12 18:29:15 2018
From: amy at demarco.com (Amy Marrich)
Date: Fri, 12 Oct 2018 13:29:15 -0500
Subject: [Openstack] Rename Cinder Volume
In-Reply-To: <66bcec61439b4432805bf25ac470e7af@granddial.com>
References: <66bcec61439b4432805bf25ac470e7af@granddial.com>
Message-ID: <CAFs83QrucbnDz8YFmdNKUOjXpuye8yjnC_rq762HJ1eUW87CsA@mail.gmail.com>

Torin,

It can be done in the Horizon dashboard as well as on the CLI with the
openstack volume set command.

Thanks,

Amy (spotz)

On Fri, Oct 12, 2018 at 1:11 PM, Torin Woltjer <torin.woltjer at granddial.com>
wrote:

> Is it possible to change the name and description of a Cinder volume?
>
> *Torin Woltjer*
>
> *Grand Dial Communications - A ZK Tech Inc. Company*
>
> *616.776.1066 ext. 2006*
> * <http://www.granddial.com>www.granddial.com <http://www.granddial.com>*
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181012/c3bb40ef/attachment.html>

From torin.woltjer at granddial.com  Fri Oct 12 18:32:45 2018
From: torin.woltjer at granddial.com (Torin Woltjer)
Date: Fri, 12 Oct 2018 18:32:45 GMT
Subject: [Openstack] Rename Cinder Volume
Message-ID: <c265e14bc81e4910ba0e98a82d942710@granddial.com>

That was easy, Thanks!

Torin Woltjer
 
Grand Dial Communications - A ZK Tech Inc. Company
 
616.776.1066 ext. 2006
www.granddial.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181012/2e6b4e41/attachment.html>

From eblock at nde.ag  Fri Oct 12 21:50:27 2018
From: eblock at nde.ag (Eugen Block)
Date: Fri, 12 Oct 2018 21:50:27 +0000
Subject: [Openstack] [Nova][Glance] Nova imports flat images from base
 file despite ceph backend
In-Reply-To: <679352a8-c082-d851-d8a5-ea7b2348b7d3@gmail.com>
References: <20180928115051.Horde.ZC_55UzSXeK4hiOjJt6tajA@webmail.nde.ag>
 <A24869C3-C782-48AA-A583-13D435D0356F@enter.eu>
 <20180928125224.Horde.33aqtdk0B9Ncylg-zxjA5to@webmail.nde.ag>
 <9F3C86CE-862D-469A-AD79-3F334CD5DB41@enter.eu>
 <CAHUi5cOtbC9VFaHD0yUeZDF3HqsipLRQ8h43vU-Beqr-ecz3vA@mail.gmail.com>
 <BE4AC4DD-FB62-4C72-ACFA-37E7F5C47CE4@enter.eu>
 <20181004124417.Horde.py2wEG4JmO1oFXbjX5u1uw3@webmail.nde.ag>
 <20181009080101.Horde.---iO9LIrKkWvTsNJwWk_Mj@webmail.nde.ag>
 <679352a8-c082-d851-d8a5-ea7b2348b7d3@gmail.com>
Message-ID: <20181012215027.Horde.t5xm_KfkoEE4YEnrewHQZPG@webmail.nde.ag>

Hi Melanie,

thanks for your response.

I would consider this thread as closed. After I learned that nova  
imports flat images if the image's disk-format is not "raw" I tested  
some different scenarios to understand more about this topic. I still  
couldn't explain why nova did that in the specific case as I was sure  
the image's format was raw (the image has been deleted in the meantime  
but I can see in the database that the image's disk-format was indeed  
"raw").

But a couple of days ago I encountered the same problem. I tried to  
upload an image from volume via Horizon dashboard (where a dropdown  
exists to choose disk-format) and the preselected value was indeed  
"qcow2" instead of "raw". I have no idea *why* it was different from  
the default "raw" but this could have happened last week, too, althoug  
according to the database entry it should not have happened. Anyway,  
now I know the reason why some ephemeral disks are flat, I just can't  
tell how Horizon selects the format, but that's enough research for  
now. If I find out more I'll report back.

Thanks again!
Regards,
Eugen


Zitat von melanie witt <melwittt at gmail.com>:

> On Tue, 09 Oct 2018 08:01:01 +0000, Eugen Block wrote:
>> So it's still unclear why nova downloaded a raw glance image to the
>> local filesystem during the previous attempt.
>>
>> I always knew that with Ceph as backend it's recommended to use raw
>> images but I always assumed the "disk-format" was not more than a
>> display option. Well, now I know that, but this still doesn't explain
>> the downloaded base image.
>> If anyone has an idea how to reproduce such behavior or an
>> explanation, I'd love to hear it.
>
> Right, in order to get the ceph CoW behavior, you must use RAW  
> glance image format [1]. You also need to have created the image as  
> 'raw' before you upload to glance (qemu-img info should show the  
> file format as 'raw').
>
> If you have done this, then you shouldn't see any image downloaded  
> to the local filesystem. Is it possible that your image did not have  
> file format 'raw' before you uploaded it to glance?
>
> Cheers,
> -melanie
>
> [1] http://docs.ceph.com/docs/master/rbd/rbd-openstack
>
>
>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack





From melwittt at gmail.com  Sat Oct 13 00:17:12 2018
From: melwittt at gmail.com (melanie witt)
Date: Fri, 12 Oct 2018 17:17:12 -0700
Subject: [Openstack] [Nova][Glance] Nova imports flat images from base
 file despite ceph backend
In-Reply-To: <20181012215027.Horde.t5xm_KfkoEE4YEnrewHQZPG@webmail.nde.ag>
References: <20180928115051.Horde.ZC_55UzSXeK4hiOjJt6tajA@webmail.nde.ag>
 <A24869C3-C782-48AA-A583-13D435D0356F@enter.eu>
 <20180928125224.Horde.33aqtdk0B9Ncylg-zxjA5to@webmail.nde.ag>
 <9F3C86CE-862D-469A-AD79-3F334CD5DB41@enter.eu>
 <CAHUi5cOtbC9VFaHD0yUeZDF3HqsipLRQ8h43vU-Beqr-ecz3vA@mail.gmail.com>
 <BE4AC4DD-FB62-4C72-ACFA-37E7F5C47CE4@enter.eu>
 <20181004124417.Horde.py2wEG4JmO1oFXbjX5u1uw3@webmail.nde.ag>
 <20181009080101.Horde.---iO9LIrKkWvTsNJwWk_Mj@webmail.nde.ag>
 <679352a8-c082-d851-d8a5-ea7b2348b7d3@gmail.com>
 <20181012215027.Horde.t5xm_KfkoEE4YEnrewHQZPG@webmail.nde.ag>
Message-ID: <9df7167b-ea3b-51d6-9fad-7c9298caa7be@gmail.com>

On Fri, 12 Oct 2018 21:50:27 +0000, Eugen Block wrote:
> I would consider this thread as closed. After I learned that nova
> imports flat images if the image's disk-format is not "raw" I tested
> some different scenarios to understand more about this topic. I still
> couldn't explain why nova did that in the specific case as I was sure
> the image's format was raw (the image has been deleted in the meantime
> but I can see in the database that the image's disk-format was indeed
> "raw").

Thanks for sharing that info. The reason I suggested that maybe the 
original image wasn't created with 'raw' format (example, with 'qemu-img 
create -f raw ...') was because I have made that mistake before in the 
past. :P It is possible to upload an image to glance that is not format 
'raw' and also specify to glance that it _is_ indeed 'raw' (I used the 
openstack CLI when I did the image upload). In that case, you will see 
nova download the image instead of doing ceph CoW clone.

> But a couple of days ago I encountered the same problem. I tried to
> upload an image from volume via Horizon dashboard (where a dropdown
> exists to choose disk-format) and the preselected value was indeed
> "qcow2" instead of "raw". I have no idea*why*  it was different from
> the default "raw" but this could have happened last week, too, althoug
> according to the database entry it should not have happened. Anyway,
> now I know the reason why some ephemeral disks are flat, I just can't
> tell how Horizon selects the format, but that's enough research for
> now. If I find out more I'll report back.

Sure, let us know if you notice anything else unusual.

Cheers,
-melanie





From remo at italy1.com  Sat Oct 13 03:06:04 2018
From: remo at italy1.com (Remo Mattei)
Date: Fri, 12 Oct 2018 20:06:04 -0700
Subject: [Openstack] [Nova][Glance] Nova imports flat images from base
	file despite ceph backend
In-Reply-To: <9df7167b-ea3b-51d6-9fad-7c9298caa7be@gmail.com>
References: <20180928115051.Horde.ZC_55UzSXeK4hiOjJt6tajA@webmail.nde.ag>
 <A24869C3-C782-48AA-A583-13D435D0356F@enter.eu>
 <20180928125224.Horde.33aqtdk0B9Ncylg-zxjA5to@webmail.nde.ag>
 <9F3C86CE-862D-469A-AD79-3F334CD5DB41@enter.eu>
 <CAHUi5cOtbC9VFaHD0yUeZDF3HqsipLRQ8h43vU-Beqr-ecz3vA@mail.gmail.com>
 <BE4AC4DD-FB62-4C72-ACFA-37E7F5C47CE4@enter.eu>
 <20181004124417.Horde.py2wEG4JmO1oFXbjX5u1uw3@webmail.nde.ag>
 <20181009080101.Horde.---iO9LIrKkWvTsNJwWk_Mj@webmail.nde.ag>
 <679352a8-c082-d851-d8a5-ea7b2348b7d3@gmail.com>
 <20181012215027.Horde.t5xm_KfkoEE4YEnrewHQZPG@webmail.nde.ag>
 <9df7167b-ea3b-51d6-9fad-7c9298caa7be@gmail.com>
Message-ID: <72242CC2-621E-4037-A8F0-8AE56C4A6F36@italy1.com>

Hi all
I do not have it handy now but you can verify that the image is indeed raw or qcow2 

As soon as I get home I will dig the command and pass it on. I have seen where images have extensions thinking it is raw and it is not. 

Remo 

>> Il giorno 12 ott 2018, alle ore 17:17, melanie witt <melwittt at gmail.com> ha scritto:
>> 
>> On Fri, 12 Oct 2018 21:50:27 +0000, Eugen Block wrote:
>> I would consider this thread as closed. After I learned that nova
>> imports flat images if the image's disk-format is not "raw" I tested
>> some different scenarios to understand more about this topic. I still
>> couldn't explain why nova did that in the specific case as I was sure
>> the image's format was raw (the image has been deleted in the meantime
>> but I can see in the database that the image's disk-format was indeed
>> "raw").
> 
> Thanks for sharing that info. The reason I suggested that maybe the original image wasn't created with 'raw' format (example, with 'qemu-img create -f raw ...') was because I have made that mistake before in the past. :P It is possible to upload an image to glance that is not format 'raw' and also specify to glance that it _is_ indeed 'raw' (I used the openstack CLI when I did the image upload). In that case, you will see nova download the image instead of doing ceph CoW clone.
> 
>> But a couple of days ago I encountered the same problem. I tried to
>> upload an image from volume via Horizon dashboard (where a dropdown
>> exists to choose disk-format) and the preselected value was indeed
>> "qcow2" instead of "raw". I have no idea*why*  it was different from
>> the default "raw" but this could have happened last week, too, althoug
>> according to the database entry it should not have happened. Anyway,
>> now I know the reason why some ephemeral disks are flat, I just can't
>> tell how Horizon selects the format, but that's enough research for
>> now. If I find out more I'll report back.
> 
> Sure, let us know if you notice anything else unusual.
> 
> Cheers,
> -melanie
> 
> 
> 
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



From cdent+os at anticdent.org  Mon Oct 15 10:55:16 2018
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 15 Oct 2018 11:55:16 +0100 (BST)
Subject: [Openstack] [openstack] openstack setups at Universities
In-Reply-To: <CAD33W0y1cxtnrdaA-cYb_PWC3Mz+NoMWTkKgkrfm41FAOLaj8w@mail.gmail.com>
References: <CAD33W0y1cxtnrdaA-cYb_PWC3Mz+NoMWTkKgkrfm41FAOLaj8w@mail.gmail.com>
Message-ID: <alpine.OSX.2.21.1810151154290.16866@cdent-a01.vmware.com>

On Wed, 10 Oct 2018, Jay See wrote:

> Hai everyone,
>
> May be a different question , not completely related to issues associated
> with openstack.
>
> Does anyone know any university or universities using opnstack for cloud
> deployment and resource sharing.

Jetstream is OpenStack-based and put together by a consortium of
universities: https://jetstream-cloud.org/


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From kennelson11 at gmail.com  Tue Oct 16 00:33:22 2018
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Mon, 15 Oct 2018 17:33:22 -0700
Subject: [Openstack] [openstack] openstack setups at Universities
In-Reply-To: <alpine.OSX.2.21.1810151154290.16866@cdent-a01.vmware.com>
References: <CAD33W0y1cxtnrdaA-cYb_PWC3Mz+NoMWTkKgkrfm41FAOLaj8w@mail.gmail.com>
 <alpine.OSX.2.21.1810151154290.16866@cdent-a01.vmware.com>
Message-ID: <CAJ6yrQgVbCwtzKSGMAV1pMLbj9eHqwxQ4SQo21vNA6Bd95Mj3w@mail.gmail.com>

Hello,

The Federal University of Rio de Janeiro also has an OpenStack cloud on
their campus. I can't find any details on their site, but if you contact
professor Claudio Miceli de Farias, he can definitely give you details. His
email address is claudiofarias at nce.ufrj.br

-Kendall (diablo_rojo)

On Mon, Oct 15, 2018 at 4:04 AM Chris Dent <cdent+os at anticdent.org> wrote:

> On Wed, 10 Oct 2018, Jay See wrote:
>
> > Hai everyone,
> >
> > May be a different question , not completely related to issues associated
> > with openstack.
> >
> > Does anyone know any university or universities using opnstack for cloud
> > deployment and resource sharing.
>
> Jetstream is OpenStack-based and put together by a consortium of
> universities: https://jetstream-cloud.org/
>
>
> --
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw:
> @anticdent_______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181015/5e44cd85/attachment.html>

From emccormick at cirrusseven.com  Tue Oct 16 17:20:37 2018
From: emccormick at cirrusseven.com (Erik McCormick)
Date: Tue, 16 Oct 2018 13:20:37 -0400
Subject: [Openstack] Ops Meetups - Call for Hosts
Message-ID: <CAHUi5cOM+HOHAS9RE4j-ZMvjepD1JRWJxst5uAt6KgvnSga5OA@mail.gmail.com>

Hello all,

The Ops Meetup team has embarked on a mission to revive the
traditional Operators Meetup that have historically been held between
Summits. With the upcoming merger of the PTG into the Summit week, and
the merger of most Ops discussion sessions at Summits into the Forum,
we felt that we needed to get back to our original format.

With that in mind, we are beginning the process of selecting venues
for both 2019 Meetups. Some guidelines for what is needed to host can
be found here:
https://wiki.openstack.org/wiki/Operations/Meetups#Venue_Selection

Each of the etherpads below contains a template to collect information
about the potential host and venue. If you are interested in hosting a
meetup, simply copy and paste the template into a blank etherpad, fill
it out, and place a link above the template on the original etherpad.

Ops Meetup 2019 #1 - Late February / Early March - Somewhere in Europe
https://etherpad.openstack.org/p/ops-meetup-venue-discuss-1st-2019

Ops Meetup 2019 #2 - Late July / Early August - Somewhere in North America
https://etherpad.openstack.org/p/ops-meetup-venue-discuss-2nd-2019

Reply back to this thread with any questions or comments. If you are
coming to the Berlin Summit, we will be having an Ops Meetup Team
catch-up Forum session. We encourage all of you to join in making
these events a success.

Cheers,
Erik


From pramod.polo at yahoo.in  Wed Oct 17 06:03:42 2018
From: pramod.polo at yahoo.in (Pramod Polo)
Date: Wed, 17 Oct 2018 06:03:42 +0000 (UTC)
Subject: [Openstack] Editing a Flavor Access changes its Flavor ID for
	running instance
References: <1720353879.10074317.1539756222074.ref@mail.yahoo.com>
Message-ID: <1720353879.10074317.1539756222074@mail.yahoo.com>

 Hello,

I have a newton setup in production on centos.

I edited the flavor access of a running instance to a selected project, on changing the flavor acces, the flavor id got changed and size of the instance says "Not available" and there is an error in the upper right saying "Error: Unable to retrieve instance size information."

How do I replace the old flavor id of the instance that is holding the old id to a new flavor id from the database. Is it possible to do so???

Or is there any better solution for this.

Any suggestions on this. Please help.

Regards,
Pramod Polo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181017/f61cd1f5/attachment.html>

From pramod.polo at yahoo.in  Wed Oct 17 07:15:31 2018
From: pramod.polo at yahoo.in (Pramod Polo)
Date: Wed, 17 Oct 2018 07:15:31 +0000 (UTC)
Subject: [Openstack] [openstack-dev][nova] Changing Flavor access changes
	Flavor ID
References: <1166343105.10136507.1539760531681.ref@mail.yahoo.com>
Message-ID: <1166343105.10136507.1539760531681@mail.yahoo.com>

Hello,

I have a newton setup in production on centos.

I edited the flavor access of a running instance to a selected project, on changing the flavor access, the flavor id got changed and size of the instance says "Not available" and there is an error in the upper right saying "Error: Unable to retrieve instance size information."

How do I replace the old flavor id of the instance that is holding the old id to a new flavor id from the database. Is it possible to do so???

Or is there any better solution for this.

Any suggestions on this. Please help.

Regards,
Pramod Polo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181017/aae3c365/attachment.html>

From pkliczew at redhat.com  Wed Oct 17 07:41:10 2018
From: pkliczew at redhat.com (Piotr Kliczewski)
Date: Wed, 17 Oct 2018 09:41:10 +0200
Subject: [Openstack] =?utf-8?q?_FOSDEM=E2=80=9819_Virtualization_=26_IaaS_?=
	=?utf-8?q?Devroom_CfP?=
Message-ID: <CAGEt_QYdHF4iMrsrtqzpL25a356h1nd9LdZmidP3KY9OkvnD-g@mail.gmail.com>

We are excited to announce that the

call for proposals is now open for the Virtualization & IaaS devroom at the

upcoming FOSDEM 2019, to be hosted on February 2nd 2019.

This year will mark FOSDEM’s 19th anniversary as one of the longest-running

free and open source software developer events, attracting thousands of

developers and users from all over the world. FOSDEM will be held once

again in Brussels, Belgium, on February 2nd & 3rd, 2019.

This devroom is a collaborative effort, and is organized by dedicated folks

from projects such as OpenStack, Xen Project, oVirt, QEMU, KVM, and

Foreman. We would like to invite all those who are involved in these fields

to submit your proposals by December 1st, 2018.

About the Devroom

The Virtualization & IaaS devroom will feature session topics such as open

source hypervisors and virtual machine managers such as Xen Project, KVM,

bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as
KubeVirt,

Apache CloudStack, OpenStack, oVirt, QEMU and OpenNebula.

This devroom will host presentations that focus on topics of shared

interest, such as KVM; libvirt; shared storage; virtualized networking;

cloud security; clustering and high availability; interfacing with multiple

hypervisors; hyperconverged deployments; and scaling across hundreds or

thousands of servers.

Presentations in this devroom will be aimed at developers working on these

platforms who are looking to collaborate and improve shared infrastructure

or solve common problems. We seek topics that encourage dialog between

projects and continued work post-FOSDEM.

Important Dates

Submission deadline: 1 December 2019

Acceptance notifications: 14 December 2019

Final schedule announcement: 21 December 2019

Devroom: 2nd February 2019

Submit Your Proposal

All submissions must be made via the Pentabarf event planning site[1]. If

you have not used Pentabarf before, you will need to create an account. If

you submitted proposals for FOSDEM in previous years, you can use your

existing account.

After creating the account, select Create Event to start the submission

process. Make sure to select Virtualization and IaaS devroom from the Track

list. Please fill out all the required fields, and provide a meaningful

abstract and description of your proposed session.

Submission Guidelines

We expect more proposals than we can possibly accept, so it is vitally

important that you submit your proposal on or before the deadline. Late

submissions are unlikely to be considered.

All presentation slots are 30 minutes, with 20 minutes planned for

presentations, and 10 minutes for Q&A.

All presentations will be recorded and made available under Creative

Commons licenses. In the Submission notes field, please indicate that you

agree that your presentation will be licensed under the CC-By-SA-4.0 or

CC-By-4.0 license and that you agree to have your presentation recorded.

For example:

"If my presentation is accepted for FOSDEM, I hereby agree to license all

recordings, slides, and other associated materials under the Creative

Commons Attribution Share-Alike 4.0 International License. Sincerely,

<NAME>."

In the Submission notes field, please also confirm that if your talk is

accepted, you will be able to attend FOSDEM and deliver your presentation.

We will not consider proposals from prospective speakers who are unsure

whether they will be able to secure funds for travel and lodging to attend

FOSDEM. (Sadly, we are not able to offer travel funding for prospective

speakers.)

Speaker Mentoring Program

As a part of the rising efforts to grow our communities and encourage a

diverse and inclusive conference ecosystem, we're happy to announce that

we'll be offering mentoring for new speakers. Our mentors can help you with

tasks such as reviewing your abstract, reviewing your presentation outline

or slides, or practicing your talk with you.

You may apply to the mentoring program as a newcomer speaker if you:

Never presented before or

Presented only lightning talks or

Presented full-length talks at small meetups (<50 ppl)

Submission Guidelines

Mentored presentations will have 25-minute slots, where 20 minutes will

include the presentation and 5 minutes will be reserved for questions.

The number of newcomer session slots is limited, so we will probably not be

able to accept all applications.

You must submit your talk and abstract to apply for the mentoring program,

our mentors are volunteering their time and will happily provide feedback

but won't write your presentation for you!

If you are experiencing problems with Pentabarf, the proposal submission

interface, or have other questions, you can email our devroom mailing

list[2] and we will try to help you.

How to Apply

In addition to agreeing to video recording and confirming that you can

attend FOSDEM in case your session is accepted, please write "speaker

mentoring program application" in the "Submission notes" field, and list

any prior speaking experience or other relevant information for your

application.

Call for Mentors

Interested in mentoring newcomer speakers? We'd love to have your help!

Please email iaas-virt-devroom at lists.fosdem.org with a short speaker

biography and any specific fields of expertise (for example, KVM,

OpenStack, storage, etc.) so that we can match you with a newcomer speaker

from a similar field. Estimated time investment can be as low as a 5-10

hours in total, usually distributed weekly or bi-weekly.

Never mentored a newcomer speaker but interested to try? As the mentoring

program coordinator, email Brian Proffitt[3] and he will be happy to answer
your questions!

Code of Conduct

Following the release of the updated code of conduct for FOSDEM, we'd like

to remind all speakers and attendees that all of the presentations and

discussions in our devroom are held under the guidelines set in the CoC and

we expect attendees, speakers, and volunteers to follow the CoC at all

times.

If you submit a proposal and it is accepted, you will be required to

confirm that you accept the FOSDEM CoC. If you have any questions about the

CoC or wish to have one of the devroom organizers review your presentation

slides or any other content for CoC compliance, please email us and we will

do our best to assist you.

Call for Volunteers

We are also looking for volunteers to help run the devroom. We need

assistance watching time for the speakers, and helping with video for the

devroom. Please contact Brian Proffitt, for more information.

Questions?

If you have any questions about this devroom, please send your questions to

our devroom mailing list. You can also subscribe to the list to receive

updates about important dates, session announcements, and to connect with

other attendees.

See you all at FOSDEM!

[1] <https://penta.fosdem.org/submission/FOSDEM17>
https://penta.fosdem.org/submission/FOSDEM19

[2] iaas-virt-devroom at lists.fosdem.org
<https://lists.fosdem.org/listinfo/fosdem>

[3] bkp at redhat.com <https://lists.fosdem.org/listinfo/fosdem>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181017/a8d5ff82/attachment.html>

From robert at componentsoft.io  Wed Oct 17 15:24:57 2018
From: robert at componentsoft.io (Robert Varjasi)
Date: Wed, 17 Oct 2018 17:24:57 +0200
Subject: [Openstack] nova-api-os-compute slowdown
In-Reply-To: <915bf691-d741-dd9c-7143-050088b5700b@componentsoft.io>
References: <c6b6426e-49d9-a7f1-f741-135181a06216@componentsoft.io>
 <915bf691-d741-dd9c-7143-050088b5700b@componentsoft.io>
Message-ID: <fa211d30-a781-9120-6f93-308f9de3fbef@componentsoft.io>

Hi,

Finally, the issue solved. It is caused by the low number of connections
set to memcached servers: 1024. I noticed too many files open and too
many sockets errors in my logs. Changing the memcached max allowed
connections to 2048 or higher solved my problem.

You can check your memcached server: echo stats|nc localhost 11211|grep
listen_disabled . If you have listen_disabled > 1 you need to increase
the max connections for you memcached server.

For the OSA you need to set this parameter: |memcached_connections: 4096|

Regards,
Robert Varjasi
consultant at Component Soft Ltd.
Tel: +36/30-259-9221

On 10/12/2018 04:35 PM, Robert Varjasi wrote:
> Hi,
>
> I found that my controller nodes were a bit overloaded with 16 uwsgi
> nova-api-os compute processes. I reduced the nova-api-os uwsgi processes
> to 10 and timeout and slowdowns were eliminated. My cloud went stable
> and the response times went lower. I have 20 vcpus on a Xeon(R) CPU
> E5-2630 v4 @ 2.20GHz.
>
> For the openstack-ansible I need to change this variable from 16 to 10:
> nova_wsgi_processes_max: 10. Seems I need to set it to an equal number
> of my cpu cores.
>
> Regards,
> Robert Varjasi
> consultant at Component Soft Ltd.
> Tel: +36/30-259-9221
>
> On 10/08/2018 06:33 PM, Robert Varjasi wrote:
>> Hi,
>>
>> After a few tempest run I noticed slowdowns in the nova-api-os-compute
>> uwsgi  processes. I check the processes with py-spy and found that a lot
>> of process blocked on read(). Here is my py-spy output from one of my
>> nova-api-os-compute uwsgi process: http://paste.openstack.org/show/731677/
>>
>> And the stack trace:
>>
>> thread_id = Thread-2 filename = /usr/lib/python2.7/threading.py lineno =
>> 774 function = __bootstrap line = self.__bootstrap_inner()
>> thread_id = Thread-2 filename = /usr/lib/python2.7/threading.py lineno =
>> 801 function = __bootstrap_inner line = self.run()
>> thread_id = Thread-2 filename = /usr/lib/python2.7/threading.py lineno =
>> 754 function = run line = self.__target(*self.__args, **self.__kwargs)
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py
>> lineno = 382 function = poll line =
>> self.conn.consume(timeout=current_timeout)
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
>> lineno = 1083 function = consume line = error_callback=_error_callback)
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
>> lineno = 807 function = ensure line = ret, channel = autoretry_method()
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/connection.py
>> lineno = 494 function = _ensured line = return fun(*args, **kwargs)
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/connection.py
>> lineno = 570 function = __call__ line = return fun(*args,
>> channel=channels[0], **kwargs), channels[0]
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
>> lineno = 796 function = execute_method line = method()
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py
>> lineno = 1068 function = _consume line =
>> self.connection.drain_events(timeout=poll_timeout)
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/connection.py
>> lineno = 301 function = drain_events line = return
>> self.transport.drain_events(self.connection, **kwargs)
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/kombu/transport/pyamqp.py
>> lineno = 103 function = drain_events line = return
>> connection.drain_events(**kwargs)
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/connection.py
>> lineno = 471 function = drain_events line = while not
>> self.blocking_read(timeout):
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/connection.py
>> lineno = 476 function = blocking_read line = frame =
>> self.transport.read_frame()
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/transport.py
>> lineno = 226 function = read_frame line = frame_header = read(7, True)
>> thread_id = Thread-2 filename =
>> /openstack/venvs/nova-17.0.4/lib/python2.7/site-packages/amqp/transport.py
>> lineno = 346 function = _read line = s = recv(n - len(rbuf))  # see note
>> above
>> thread_id = Thread-2 filename = /usr/lib/python2.7/ssl.py lineno = 643
>> function = read line = v = self._sslobj.read(len)
>>
>> I am using nova 17.0.4.dev1, amqp (2.2.2), oslo.messaging (5.35.0),
>> kombu (4.1.0). I have 3 controller nodes. The openstack deployed by OSA
>> 17.0.4.
>>
>> I can reproduce the read() block if I click on "Log" in Horizon to see
>> the console outputs from one of my VM or run a tempest test:
>> tempest.api.compute.admin.test_hypervisor.HypervisorAdminTestJSON.test_get_hypervisor_uptime.
>>
>> The nova-api response time increasing when more and more nova-api
>> processes get blocked at this read. Is it a normal behavior?
>>
>> --- 
>> Regards,
>> Robert Varjasi
>> consultant at Component Soft Ltd.
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181017/3e66fe4c/attachment.html>

From mranga at gmail.com  Wed Oct 17 17:32:25 2018
From: mranga at gmail.com (M. Ranganathan)
Date: Wed, 17 Oct 2018 13:32:25 -0400
Subject: [Openstack] Struggling with Octavia install / configuration.
Message-ID: <CAHiu4JNgciZP8vhMWpFTLLS39W0uwgOhV939aS17pJ9o6kwvBg@mail.gmail.com>

Hello all,

I am getting acquainted with octavia (and I have very little experience
with openstack). I have a difficult time configuring it. I am running a
multi node environment where I am installing components individually.   I
did the following on my controller node
1. Pip install octavia
2. Modify /etc/neutron/neutron.conf as follows:
[DEFAULT]
service_plugins=router,lbaasv2

[service_providers]
service_provider =
LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default

It appears the service plugin cannot be loaded.


 Could not load neutron_lbaas.drivers.octavia.driver.OctaviaDriver

And also

nrecoverable error: please check log for details.: ProgrammingError:
(pymysql.err.ProgrammingError) (1146, u"Table 'neutron.lbaas_loadbalancers'
doesn't exist") [SQL: u'SELECT lbaas_loadbalancers.project_id AS
lbaas_loadbalancers_project_id, lbaas_loadbalancers.id AS
lbaas_loadbalancers_id, lbaas_loadbalancers.name AS
lbaas_loadbalancers_name, lbaas_loadbalancers.description AS
lbaas_loadbalancers_description, lbaas_loadbalancers.vip_subnet_id AS
lbaas_loadbalancers_vip_subnet_id, lbaas_loadbalancers.vip_port_id AS
lbaas_loadbalancers_vip_port_id, lbaas_loadbalancers.vip_address AS
lbaas_loadbalancers_vip_address, lbaas_loadbalancers.provisioning_status AS
lbaas_loadbalancers_provisioning_status,
lbaas_loadbalancers.operating_status AS
lbaas_loadbalancers_operating_status, lbaas_loadbalancers.admin_state_up AS
lbaas_loadbalancers_admin_state_up, lbaas_loadbalancers.flavor_id AS
lbaas_loadbalancers_flavor_id \nFROM lbaas_loadbalancers']


it appears I have missed some important configuration step. Thanks in
advance for any help.

Ranga



-- 
M. Ranganathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181017/d9afe21b/attachment.html>

From fichera.sil at gmail.com  Thu Oct 18 17:09:24 2018
From: fichera.sil at gmail.com (Silvia Fichera)
Date: Thu, 18 Oct 2018 19:09:24 +0200
Subject: [Openstack] Problems with SFC Devstack Ocata
Message-ID: <CAEFdjR0bau6HeWkLwSwFfehPsNB3RnFnYB89Hcfn6kqH==O2nw@mail.gmail.com>

Hi all, I've installed Openstack Ocata using devstack. 1 controller +
compute and 2 compute nodes. Than I have followed
https://docs.openstack.org/networking...
<https://docs.openstack.org/networking-sfc/latest/install/configuration.html>
and https://docs.openstack.org/networking...
<https://docs.openstack.org/networking-sfc/latest/contributor/system_design_and_workflow.html>

to deploy a SFC. In my setup I have: 6 ports 1 src attached to port 1 1 dst
attached to port 6 2 SFs respectively attached to port 2 and 3 and port 4
and 5. Everything is in the same subnet.

I have 3 problems/questions:

1: I don't know why, the VMs are instantiated only in the
Controller+Compute node. Maybe a problem of Ocata?

I did a capture on the tap interface referred to the ports. I noticed that

2: Only the first packet is in the instances selected as VNF and not all
the packets. At src and dst I see all the packets

3: I have checked the timestamp of the firts packet and they have a wrong
order, in particular: src, dst, VNF1, VNF2

Moreover, I would like to know how to add onos as in these slides
https://www.openstack.org/assets/pres...
<https://www.openstack.org/assets/presentation-media/SFC-for-OpenStack-Austin-Aummit-publich.pdf>,
and what Onos controlls in this case.

Is anyone able to help me?

Thanks a lot Silvia

-- 
Silvia Fichera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181018/5eb3fd4e/attachment.html>

From jim at jokken.com  Thu Oct 18 20:07:20 2018
From: jim at jokken.com (Jim Okken)
Date: Thu, 18 Oct 2018 16:07:20 -0400
Subject: [Openstack] [Cinder] HP MSA array as a secondary backend is
 only used user is an admin
In-Reply-To: <CAMG=QuoGOS02+nXdmUJpXDT5w5Wdch_tcaRrNnEAj0sNtu+Qog@mail.gmail.com>
References: <CAMG=QuoGOS02+nXdmUJpXDT5w5Wdch_tcaRrNnEAj0sNtu+Qog@mail.gmail.com>
Message-ID: <CAMG=QuoBpDP4cAeFvXSJ8Wugpz6CvMowCLvNv4xYpDoTTRwD+w@mail.gmail.com>

just a bump.
can anyone offer any advice on this cinder driver
cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver?

thanks!
-- Jim


On Thu, Oct 11, 2018 at 4:08 PM Jim Okken <jim at jokken.com> wrote:

> hi All,
>
> not sure if I can find an answer here to this specific situation with the
> cinder backend driver cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver.
> If not how can I get in touch with someone more familiar with
> cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver
>
> we have a HP MSA storage array connected to most of our compute nodes and
> we are using the cinder driver
> cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver as a second backend so
> that openstack can, if directed by metadata, create volumes on it during
> instance creation. Openstack creates volumes using this MSA backend if the
> metadata of the image selected contains "cinder_image_volume_type=MSA".
> This second MSA type of volume was added to cinder.
>
> We use a CentOS-6-x86_64-GenericCloud-1707.qcow2 image which has this
> metadata added. Without this metadata RBD/CEPH images are made
>
> This works great for the admin user but not for a regular _ member_ user.
>
> With the admin user volumes created show Type=*MSA* and
> Host=node-44.domain.com@*MSA#A*. (correct)
>
> With the _member_ user volumes created show Type=*MSA* but
> Host=rbd:volumes at RBD-backend#*RBD-backend (this is CEPH, incorrect!)*.
>
> And I can confirm the volume is not on the MSA. Correct RBD/CEPH volumes
> show Type=*volumes_ceph* and Host=rbd:volumes at RBD-backend#*RBD-backend*.
>
> This happens if the cinder volume type is created as a Private type or a
> Public type.
>
> I have tried to set the properties on the cinder MSA volume type for the
> specific project we want to use this volume type in, and to set the
> project-domain for this volume type. nothing has helped.
>
> can anyone shed any light on this behavior or point out anything helpful
> in the logs pls?
>
> Looking at the logs I do see the _ member_ user is a non-default-domain
> user while admin is obviously the default domain. other than that I can't
> make heads or tails of the logs.
>
> Here are logs if anyone wants to look at them:
> a bad _ member_ volume creation was UUID
> fb9047c3-1b6b-4d2b-bae8-5177e86eb1f2 https://pastebin.com/bmFAy6RR
>
> a good admin volume creation was UUID b49e33db-8ab8-489f-b7cb-092f421178c1
> https://pastebin.com/5SAecNJ2
>
> We are using Newton, thanks!!!
>
>
> -- Jim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181018/2f9e102e/attachment.html>

From nguyentrongtan124 at gmail.com  Fri Oct 19 09:39:41 2018
From: nguyentrongtan124 at gmail.com (=?utf-8?B?Tmd1eeG7hW4gVHLhu41uZyBU4bqlbg==?=)
Date: Fri, 19 Oct 2018 16:39:41 +0700
Subject: [Openstack]  [Octavia] Ask about the Amphora's flavor
Message-ID: <001801d4678f$aa61fe00$ff25fa00$@gmail.com>

Hi all!

 

We are working with Octavia project. And we see Octavia used only one flavor to create amphora VM. we have two questions:

 

1.    With the default flavor (1 vCPU, 1GB RAM, 10Gbps Network shared), how workload amphora VM can carry? (concurrent connection, request per second, active connection,…)

2.    In case of heavy workload, how can I change the amphora VM’s configuration to satisfy this user’s workload? Currently, the amphora VM’s flavor is fixed to all project.

 

 

Thanks and Best Regards!

 

Nguyen Trong Tan

 

Openstack group user VietNam.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181019/de80d3ed/attachment.html>

From thienha3110 at gmail.com  Fri Oct 19 10:03:57 2018
From: thienha3110 at gmail.com (Ha Thien)
Date: Fri, 19 Oct 2018 17:03:57 +0700
Subject: [Openstack] [Manila] What is the reason of fixing flavor_id in
	manila.conf
Message-ID: <CALo=+1q+2OR42zRx3wsDmjjZUsVXR_bko0=3q+7roP+iJb6A1w@mail.gmail.com>

Hi all!

We're working with the Manila project and using the General driver. In
manina.conf, I fix the parameter service_instance_flavor_id, so all VM
share server will have same configuration RAM, CPU. I think VM config
depends on usecases.

Can anyone please explain to me the reason of fixing flavor id?

Many thanks,

Thienha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181019/0b28d607/attachment.html>

From openstack at hauschild.it  Fri Oct 19 13:32:43 2018
From: openstack at hauschild.it (Hartwig Hauschild)
Date: Fri, 19 Oct 2018 15:32:43 +0200
Subject: [Openstack] missing ovs flows and extra interfaces in pike
Message-ID: <20181019133242.xbmibiqh6wwiwuzm@alle-irre.de>

Hi, 

[ I have no idea how much of the following information is necessary ]

We're running Openstack Pike, deployed with Openstack-Ansible 16.0.5.
The system is running on a bunch of compute-nodes and three combined
network/management-nodes, we're using OVS, DVR and VXLAN for networking.

The DVRs are set up with snat disabled, that's handled by different
systems.

We have recently noticed that we don't have north-south-connectivity in
a couple of qdhcp-netns and after a weeks worth of debugging it boils
down to missing OVS-flows on br-tun that should be directing the
northbound traffic at the node with the live snat-netns.

We also noticed that while every node has the ports for the
qdhcp-netns that belong on the node we also have a couple of taps and
flows for ports that are on other nodes.

To make that a bit clearer:
If you have network A with dhcp-services F, G, H we found that the ip
netns containing the dnsmasq for F, G, H are on nodes 1, 2, 3
respectively, but node 1 would also have the tap-interface and flows for
G on br-int dangeling freely without any netns.

Is there a simple explanation for this and maybe even a fix?

What we found so far seems to suggest we should either restart the
management-nodes or the neutron-agent-containers or at least stop, clean
and start ovs and neutron-openvswitch-agent inside the containers.

Is it possible to somehow redeploy or validate the flows from neutron to
make sure that everything is consistent apart from restarts?


-- 

Cheers, 
	Hartwig Hauschild


From dev.faz at gmail.com  Fri Oct 19 14:00:48 2018
From: dev.faz at gmail.com (Fabian Zimmermann)
Date: Fri, 19 Oct 2018 16:00:48 +0200
Subject: [Openstack] missing ovs flows and extra interfaces in pike
In-Reply-To: <20181019133242.xbmibiqh6wwiwuzm@alle-irre.de>
References: <20181019133242.xbmibiqh6wwiwuzm@alle-irre.de>
Message-ID: <eec163a5-ecfc-8c18-1155-a07a2e84f926@gmail.com>

Hi,

we see something similar. We are running ovs, vxlan - but legacy routers 
directly on hvs without any network nodes.

Currently we didnt find a way to fix or reproduce the issue. We just 
wrote a small script which calcuates which flow should be on with hv and 
if something is missing -> send an alert.

The operator will then restart the suitable ovs-agent and everything is 
working again.

We also found out, that the problem is gone as soon as we disable l2pop, 
but this is not possible if we (as you already did) switch to dvr.

So at the moment we plan to disable l2pop and move our routers back to 
some network nodes.

I would be glad if someone is able to reproduce or even better - fix the 
issue.

  Fabian

Am 19.10.18 um 15:32 schrieb Hartwig Hauschild:
> Hi,
> 
> [ I have no idea how much of the following information is necessary ]
> 
> We're running Openstack Pike, deployed with Openstack-Ansible 16.0.5.
> The system is running on a bunch of compute-nodes and three combined
> network/management-nodes, we're using OVS, DVR and VXLAN for networking.
> 
> The DVRs are set up with snat disabled, that's handled by different
> systems.
> 
> We have recently noticed that we don't have north-south-connectivity in
> a couple of qdhcp-netns and after a weeks worth of debugging it boils
> down to missing OVS-flows on br-tun that should be directing the
> northbound traffic at the node with the live snat-netns.
> 
> We also noticed that while every node has the ports for the
> qdhcp-netns that belong on the node we also have a couple of taps and
> flows for ports that are on other nodes.
> 
> To make that a bit clearer:
> If you have network A with dhcp-services F, G, H we found that the ip
> netns containing the dnsmasq for F, G, H are on nodes 1, 2, 3
> respectively, but node 1 would also have the tap-interface and flows for
> G on br-int dangeling freely without any netns.
> 
> Is there a simple explanation for this and maybe even a fix?
> 
> What we found so far seems to suggest we should either restart the
> management-nodes or the neutron-agent-containers or at least stop, clean
> and start ovs and neutron-openvswitch-agent inside the containers.
> 
> Is it possible to somehow redeploy or validate the flows from neutron to
> make sure that everything is consistent apart from restarts?
> 
> 


From dev.faz at gmail.com  Fri Oct 19 14:04:15 2018
From: dev.faz at gmail.com (Fabian Zimmermann)
Date: Fri, 19 Oct 2018 16:04:15 +0200
Subject: [Openstack] Struggling with Octavia install / configuration.
In-Reply-To: <CAHiu4JNgciZP8vhMWpFTLLS39W0uwgOhV939aS17pJ9o6kwvBg@mail.gmail.com>
References: <CAHiu4JNgciZP8vhMWpFTLLS39W0uwgOhV939aS17pJ9o6kwvBg@mail.gmail.com>
Message-ID: <196fdbc9-afff-77a6-7c64-684cbeacb5be@gmail.com>

Hi,

"table does not exists" sounds like you forgot to run the db-scripts. If 
I remember correctly something like

"octavia-db-manage"

you could *carefully* read

https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html

because important information are not marked as such :(

  Fabian

Am 17.10.18 um 19:32 schrieb M. Ranganathan:
> Hello all,
> 
> I am getting acquainted with octavia (and I have very little experience 
> with openstack). I have a difficult time configuring it. I am running a 
> multi node environment where I am installing components individually.   
> I did the following on my controller node
> 1. Pip install octavia
> 2. Modify /etc/neutron/neutron.conf as follows:
> [DEFAULT]
> service_plugins=router,lbaasv2
> 
> [service_providers]
> service_provider = 
> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
> 
> It appears the service plugin cannot be loaded.
> 
> 
>   Could not load neutron_lbaas.drivers.octavia.driver.OctaviaDriver
> 
> And also
> 
> nrecoverable error: please check log for details.: ProgrammingError: 
> (pymysql.err.ProgrammingError) (1146, u"Table 
> 'neutron.lbaas_loadbalancers' doesn't exist") [SQL: u'SELECT 
> lbaas_loadbalancers.project_id AS lbaas_loadbalancers_project_id, 
> lbaas_loadbalancers.id <http://lbaas_loadbalancers.id> AS 
> lbaas_loadbalancers_id, lbaas_loadbalancers.name 
> <http://lbaas_loadbalancers.name> AS lbaas_loadbalancers_name, 
> lbaas_loadbalancers.description AS lbaas_loadbalancers_description, 
> lbaas_loadbalancers.vip_subnet_id AS lbaas_loadbalancers_vip_subnet_id, 
> lbaas_loadbalancers.vip_port_id AS lbaas_loadbalancers_vip_port_id, 
> lbaas_loadbalancers.vip_address AS lbaas_loadbalancers_vip_address, 
> lbaas_loadbalancers.provisioning_status AS 
> lbaas_loadbalancers_provisioning_status, 
> lbaas_loadbalancers.operating_status AS 
> lbaas_loadbalancers_operating_status, lbaas_loadbalancers.admin_state_up 
> AS lbaas_loadbalancers_admin_state_up, lbaas_loadbalancers.flavor_id AS 
> lbaas_loadbalancers_flavor_id \nFROM lbaas_loadbalancers']
> 
> 
> it appears I have missed some important configuration step. Thanks in 
> advance for any help.
> 
> Ranga
> 
> 
> 
> -- 
> M. Ranganathan
> 
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 


From naftinajeh94 at gmail.com  Fri Oct 19 19:15:01 2018
From: naftinajeh94 at gmail.com (Najeh Nafti)
Date: Fri, 19 Oct 2018 21:15:01 +0200
Subject: [Openstack] openstack-summit-berlin-2018
Message-ID: <CAGJVRxqmkQpzj9qAr1_KzQFR4LkPjMtapTPXVrTEGuf4Cx8M_g@mail.gmail.com>

Dear OpenStack Project team,

My name is Najeh Nafti. I am a master degree student from Tunisia North
Africa.
I'm currently working for a thesis project based on OpenStack, but i didn't
find the need resources that can help me to realize my project.

I would like to request your approval to attend OpenStack-summit-berlin-2018
with your financial support. This event is a unique opportunity for me to
gain knowledge and insight I need to solve daily challenges and to help me
contribute to the overall goals of  my study.

Although I understand there might be financial constraints in sending me to
this event, I believe it will be an investment that results in immediate
and longer term benefits. My objectives in attending this event are:

   -

   To increase knowledge in my discipline area.


   -

   To network with my peers from all over the world to share information,
   learn how they are solving similar problems, and collaborate to find
   innovative approaches.


OpenStack-summit-berlin-2018  would be a valuable experience for me and one
that would benefit my thesis.


Thank you for your consideration.

Najeh Nafti.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181019/18027839/attachment.html>

From melwittt at gmail.com  Fri Oct 19 19:56:51 2018
From: melwittt at gmail.com (melanie witt)
Date: Fri, 19 Oct 2018 12:56:51 -0700
Subject: [Openstack] [Nova][Glance] Nova imports flat images from base
 file despite ceph backend
In-Reply-To: <72242CC2-621E-4037-A8F0-8AE56C4A6F36@italy1.com>
References: <20180928115051.Horde.ZC_55UzSXeK4hiOjJt6tajA@webmail.nde.ag>
 <A24869C3-C782-48AA-A583-13D435D0356F@enter.eu>
 <20180928125224.Horde.33aqtdk0B9Ncylg-zxjA5to@webmail.nde.ag>
 <9F3C86CE-862D-469A-AD79-3F334CD5DB41@enter.eu>
 <CAHUi5cOtbC9VFaHD0yUeZDF3HqsipLRQ8h43vU-Beqr-ecz3vA@mail.gmail.com>
 <BE4AC4DD-FB62-4C72-ACFA-37E7F5C47CE4@enter.eu>
 <20181004124417.Horde.py2wEG4JmO1oFXbjX5u1uw3@webmail.nde.ag>
 <20181009080101.Horde.---iO9LIrKkWvTsNJwWk_Mj@webmail.nde.ag>
 <679352a8-c082-d851-d8a5-ea7b2348b7d3@gmail.com>
 <20181012215027.Horde.t5xm_KfkoEE4YEnrewHQZPG@webmail.nde.ag>
 <9df7167b-ea3b-51d6-9fad-7c9298caa7be@gmail.com>
 <72242CC2-621E-4037-A8F0-8AE56C4A6F36@italy1.com>
Message-ID: <f6a8caf4-ced0-c0d4-5f3f-14a9b84dc7e0@gmail.com>

On Fri, 12 Oct 2018 20:06:04 -0700, Remo Mattei wrote:
> I do not have it handy now but you can verify that the image is indeed raw or qcow2
> 
> As soon as I get home I will dig the command and pass it on. I have seen where images have extensions thinking it is raw and it is not.

You could try 'qemu-img info <image>' and get output like this, notice 
"file format":

$ qemu-img info test.vmdk
(VMDK) image open: flags=0x2 filename=test.vmdk
image: test.vmdk
file format: vmdk
virtual size: 20M (20971520 bytes)
disk size: 17M

[1] https://en.wikibooks.org/wiki/QEMU/Images#Getting_information

-melanie





From kennelson11 at gmail.com  Fri Oct 19 19:57:05 2018
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Fri, 19 Oct 2018 12:57:05 -0700
Subject: [Openstack] openstack-summit-berlin-2018
In-Reply-To: <CAGJVRxqmkQpzj9qAr1_KzQFR4LkPjMtapTPXVrTEGuf4Cx8M_g@mail.gmail.com>
References: <CAGJVRxqmkQpzj9qAr1_KzQFR4LkPjMtapTPXVrTEGuf4Cx8M_g@mail.gmail.com>
Message-ID: <CAJ6yrQguT8ghR2s1G9go7co9PE+abB_yaLwPW6t9qPmtVida_w@mail.gmail.com>

Hello Najeh!

We do have a travel support program that is set up to help people like you
that are interested in attending the summit, but don't have the financial
means of attending. Unfortunately, the deadline for Travel Support for the
Berlin Summit has passed. Please don't give up though! We have travel
support for every summit, so the summit after Berlin, the summit will be
held in Denver, Colorado in the US and will also have travel support
opportunities. Details haven't been posted yet, but they will be here[1]
sometime after Berlin I expect.

-Kendall Nelson (diablo_rojo)

[1] https://wiki.openstack.org/wiki/Travel_Support_Program

On Fri, Oct 19, 2018 at 12:29 PM Najeh Nafti <naftinajeh94 at gmail.com> wrote:

> Dear OpenStack Project team,
>
> My name is Najeh Nafti. I am a master degree student from Tunisia North
> Africa.
> I'm currently working for a thesis project based on OpenStack, but i
> didn't find the need resources that can help me to realize my project.
>
> I would like to request your approval to attend
> OpenStack-summit-berlin-2018 with your financial support. This event is a
> unique opportunity for me to gain knowledge and insight I need to solve
> daily challenges and to help me contribute to the overall goals of  my
> study.
>
> Although I understand there might be financial constraints in sending me
> to this event, I believe it will be an investment that results in immediate
> and longer term benefits. My objectives in attending this event are:
>
>    -
>
>    To increase knowledge in my discipline area.
>
>
>    -
>
>    To network with my peers from all over the world to share information,
>    learn how they are solving similar problems, and collaborate to find
>    innovative approaches.
>
>
> OpenStack-summit-berlin-2018  would be a valuable experience for me and
> one that would benefit my thesis.
>
>
> Thank you for your consideration.
>
> Najeh Nafti.
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181019/c72847ec/attachment.html>

From nowitzki.sammy at gmail.com  Sun Oct 21 04:22:20 2018
From: nowitzki.sammy at gmail.com (Sam Huracan)
Date: Sun, 21 Oct 2018 11:22:20 +0700
Subject: [Openstack] [OpenStack] [Manila] Ask about Generic driver
Message-ID: <CAEd1pN43EWA1zw5M0uru7=qC8VJHQAqedWZ4fhCxvQgAziv81Q@mail.gmail.com>

Hi OpenStackers,

In Manila project, when I use Generic driver to create share, I realize
that the VM share's flavor is  fixed by ID in manila.conf. I really
consider why has it been?


[generic]
share_backend_name = GENERIC
share_driver = manila.share.drivers.generic.GenericShareDriver
driver_handles_share_servers = True
service_instance_flavor_id = 100

I think the VM share's configuration will depend on the shared created and
the number of VM mounted to. So how can I choose VM share's flavor for each
specific case?

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181021/0894859a/attachment.html>

From manuel.sb at garvan.org.au  Mon Oct 22 05:33:54 2018
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Mon, 22 Oct 2018 05:33:54 +0000
Subject: [Openstack] [kolla] nova-gpu support
Message-ID: <9D8A2486E35F0941A60430473E29F15B017BACEA97@MXDB2.ad.garvan.unsw.edu.au>

Dear Openstack/Kolla community,

I am planning to deploy Openstack environment on nodes with Nvidia P100 GPUs and I was wondering whether the version of Openstack deployed by the latest kolla-ansible (stable) would support that. My end goal is to be able to provision VMs on KVM with GPUs support.

Any idea?

Thank you very much

Manuel Sopena Ballesteros | Big data Engineer
Garvan Institute of Medical Research
The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010
T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: manuel.sb at garvan.org.au<mailto:manuel.sb at garvan.org.au>

NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181022/e602f689/attachment.html>

From manuel.sb at garvan.org.au  Mon Oct 22 06:01:13 2018
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Mon, 22 Oct 2018 06:01:13 +0000
Subject: [Openstack] [kolla] nova-gpu support
Message-ID: <9D8A2486E35F0941A60430473E29F15B017BACEDC4@MXDB2.ad.garvan.unsw.edu.au>

Forgot to mention that the compute nodes will have x4 NVidia V100 SXM2 cards

Thank you

Manuel

From: Manuel Sopena Ballesteros
Sent: Monday, October 22, 2018 4:34 PM
To: openstack at lists.openstack.org
Subject: [kolla] nova-gpu support

Dear Openstack/Kolla community,

I am planning to deploy Openstack environment on nodes with Nvidia P100 GPUs and I was wondering whether the version of Openstack deployed by the latest kolla-ansible (stable) would support that. My end goal is to be able to provision VMs on KVM with GPUs support.

Any idea?

Thank you very much

Manuel Sopena Ballesteros | Big data Engineer
Garvan Institute of Medical Research
The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010
T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: manuel.sb at garvan.org.au<mailto:manuel.sb at garvan.org.au>

NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181022/22e8a742/attachment.html>

From manojawapv at biarca.com  Mon Oct 22 14:21:34 2018
From: manojawapv at biarca.com (Manojawa Paritala)
Date: Mon, 22 Oct 2018 19:51:34 +0530
Subject: [Openstack] Issues configuring DPDK settings in openstack queens
Message-ID: <CALqHQc3EXGPNukPCqM-2pMcZ9Bcp=UtJbe7H-W-rwrG2qF_UxA@mail.gmail.com>

Hello All,

On a 3 node (one controller + 2 compute), we configured Openstack
Queens using OSA with OVS. On all the nodes, we defined br-mgmt as
linux bridge, br-tun as private network and br-flat as external.
Installation was successful and we could create networks and
instances on Openstack.

Below are the versions of the OVS packages used on each node.

Controller :- openstack-vswitch - 2.9.0
Computes :- openstack-vswitch-dpdk - 2.9.0 (as we wanted to
configure dpdk on the compute hosts)

The openstack-vswitch-dpdk 2.9.0 package that we installed
had dpdk version 17.11.3. When we tried to enable DPDK it failed
with the below error.

dpdk|ERR|DPDK not supported in this copy of Open vSwitch

So, we downloaded the sources for dpdk 17.11.4 and openvswitch 2.9.2,
built openvswitch with dpdk as suggested in the below official link.
No issues on Openstack or OVS.
http://docs.openvswitch.org/en/latest/intro/install/dpdk/

Then, we added the below parameters to OVS and everything looked ok.
No issues in Openstack or OVS.

$ovs-vsctl get Open_vSwitch . other_config
{dpdk-extra="-n 2", dpdk-init="true", dpdk-lcore-mask="0x300000000000",
dpdk-socket-mem="4096,4096", pmd-cpu-mask="0xf00003c0000",
vhost-iommu-support="true"}

Then on the compute node, in openvswitch_agent.ini file - OVS section,
I added the below (based on the link
https://docs.openstack.org/neutron/pike/contributor/internals/ovs_vhostuser.html
)
and restarted neutron-openmvswitch-agent service.

datapath_type=netdev
vhostuser_socket_dir=/var/run/openvswitch

After the above change, bridge br-flat is getting deleted from OVS.
Attached are the logs after I restart the neutron-openmvswitch-agent
service on the compute now. Not sure what the issue is.

Can any of you please let me know if we are missing anything?

Best Regards,
PVMJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181022/a6b912ba/attachment.html>
-------------- next part --------------
2018-10-22T13:55:28.531Z|00338|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:28.532Z|00339|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:28.532Z|00340|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:28.532Z|00341|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:28.532Z|00342|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:28.823Z|00343|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:28.823Z|00344|rconn|WARN|br-flat1<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:28.823Z|00345|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: waiting 2 seconds before reconnect
2018-10-22T13:55:28.824Z|00346|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:28.824Z|00347|rconn|WARN|br-vxlan<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:28.824Z|00348|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: waiting 2 seconds before reconnect
2018-10-22T13:55:28.824Z|00349|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:28.824Z|00350|rconn|WARN|br-vlan<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:28.824Z|00351|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: waiting 2 seconds before reconnect
2018-10-22T13:55:28.824Z|00352|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:28.824Z|00353|rconn|WARN|br-int<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:28.824Z|00354|rconn|INFO|br-int<->tcp:127.0.0.1:6633: waiting 2 seconds before reconnect
2018-10-22T13:55:28.824Z|00355|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:28.824Z|00356|rconn|WARN|br-tun<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:28.824Z|00357|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: waiting 2 seconds before reconnect
2018-10-22T13:55:30.823Z|00358|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:30.823Z|00359|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:30.823Z|00360|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:30.824Z|00361|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:30.824Z|00362|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:30.870Z|00363|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:30.870Z|00364|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:30.870Z|00365|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:30.871Z|00366|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:30.871Z|00367|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:30.939Z|00368|bridge|INFO|bridge br-int: deleted interface int-br-vlan on port 2
2018-10-22T13:55:30.940Z|00369|bridge|INFO|bridge br-int: deleted interface br-int on port 65534
2018-10-22T13:55:30.940Z|00370|bridge|INFO|bridge br-int: deleted interface patch-tun on port 4
2018-10-22T13:55:30.940Z|00371|bridge|INFO|bridge br-int: deleted interface int-br-flat1 on port 1
2018-10-22T13:55:30.940Z|00372|bridge|INFO|bridge br-int: deleted interface int-br-vxlan on port 3
2018-10-22T13:55:31.530Z|00373|bridge|INFO|bridge br-int: added interface int-br-vlan on port 2
2018-10-22T13:55:31.535Z|00374|dpif_netdev|INFO|Core 42 on numa node 1 assigned port 'dpdk-p0' rx queue 0 (measured processing cycles 103120).
2018-10-22T13:55:31.535Z|00375|dpif_netdev|INFO|Core 18 on numa node 0 assigned port 'vhost-user-1' rx queue 0 (measured processing cycles 0).
2018-10-22T13:55:31.535Z|00376|bridge|INFO|bridge br-int: added interface br-int on port 65534
2018-10-22T13:55:31.536Z|00377|bridge|INFO|bridge br-int: added interface int-br-vxlan on port 3
2018-10-22T13:55:31.536Z|00378|bridge|INFO|bridge br-int: added interface int-br-flat1 on port 1
2018-10-22T13:55:31.536Z|00379|bridge|INFO|bridge br-int: added interface patch-tun on port 4
2018-10-22T13:55:31.536Z|00380|bridge|INFO|bridge br-int: using datapath ID 00002eeeccfa0248
2018-10-22T13:55:31.536Z|00381|connmgr|INFO|br-int: added service controller "punix:/var/run/openvswitch/br-int.mgmt"
2018-10-22T13:55:31.536Z|00382|connmgr|INFO|br-int: added primary controller "tcp:127.0.0.1:6633"
2018-10-22T13:55:31.536Z|00383|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:31.810Z|00384|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:32.041Z|00385|bridge|INFO|bridge br-flat1: deleted interface br-flat1 on port 65534
2018-10-22T13:55:32.042Z|00386|bridge|INFO|bridge br-flat1: deleted interface eth8 on port 1
2018-10-22T13:55:32.042Z|00387|bridge|INFO|bridge br-flat1: deleted interface phy-br-flat1 on port 2
2018-10-22T13:55:32.570Z|00388|dpif_netdev|INFO|Core 42 on numa node 1 assigned port 'dpdk-p0' rx queue 0 (measured processing cycles 103120).
2018-10-22T13:55:32.570Z|00389|dpif_netdev|INFO|Core 18 on numa node 0 assigned port 'vhost-user-1' rx queue 0 (measured processing cycles 0).
2018-10-22T13:55:32.572Z|00390|bridge|INFO|bridge br-flat1: added interface eth8 on port 1
2018-10-22T13:55:32.577Z|00391|dpif_netdev|INFO|Core 42 on numa node 1 assigned port 'dpdk-p0' rx queue 0 (measured processing cycles 103120).
2018-10-22T13:55:32.577Z|00392|dpif_netdev|INFO|Core 18 on numa node 0 assigned port 'vhost-user-1' rx queue 0 (measured processing cycles 0).
2018-10-22T13:55:32.577Z|00393|bridge|INFO|bridge br-flat1: added interface br-flat1 on port 65534
2018-10-22T13:55:32.577Z|00394|bridge|INFO|bridge br-flat1: added interface phy-br-flat1 on port 2
2018-10-22T13:55:32.577Z|00395|bridge|INFO|bridge br-flat1: using datapath ID 00003cfdfebcf7a8
2018-10-22T13:55:32.577Z|00396|connmgr|INFO|br-flat1: added service controller "punix:/var/run/openvswitch/br-flat1.mgmt"
2018-10-22T13:55:32.577Z|00397|connmgr|INFO|br-flat1: added primary controller "tcp:127.0.0.1:6633"
2018-10-22T13:55:32.577Z|00398|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:32.826Z|00399|netdev_linux|WARN|error receiving Ethernet packet on eth8: Network is down
2018-10-22T13:55:32.826Z|00400|dpif_netdev|ERR|error receiving data from eth8: Network is down
2018-10-22T13:55:32.827Z|00401|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:32.879Z|00402|bridge|INFO|bridge br-vlan: deleted interface phy-br-vlan on port 2
2018-10-22T13:55:32.880Z|00403|bridge|INFO|bridge br-vlan: deleted interface br-vlan on port 65534
2018-10-22T13:55:32.880Z|00404|bridge|INFO|bridge br-vlan: deleted interface eth10 on port 1
2018-10-22T13:55:33.431Z|00405|bridge|INFO|bridge br-vlan: added interface phy-br-vlan on port 2
2018-10-22T13:55:33.436Z|00406|dpif_netdev|INFO|Core 42 on numa node 1 assigned port 'dpdk-p0' rx queue 0 (measured processing cycles 103120).
2018-10-22T13:55:33.436Z|00407|dpif_netdev|INFO|Core 18 on numa node 0 assigned port 'vhost-user-1' rx queue 0 (measured processing cycles 0).
2018-10-22T13:55:33.436Z|00408|bridge|INFO|bridge br-vlan: added interface br-vlan on port 65534
2018-10-22T13:55:33.437Z|00409|dpif_netdev|INFO|Core 42 on numa node 1 assigned port 'dpdk-p0' rx queue 0 (measured processing cycles 103120).
2018-10-22T13:55:33.437Z|00410|dpif_netdev|INFO|Core 18 on numa node 0 assigned port 'vhost-user-1' rx queue 0 (measured processing cycles 0).
2018-10-22T13:55:33.437Z|00411|bridge|INFO|bridge br-vlan: added interface eth10 on port 1
2018-10-22T13:55:33.437Z|00412|bridge|INFO|bridge br-vlan: using datapath ID 00003cfdfebcf548
2018-10-22T13:55:33.437Z|00413|connmgr|INFO|br-vlan: added service controller "punix:/var/run/openvswitch/br-vlan.mgmt"
2018-10-22T13:55:33.437Z|00414|connmgr|INFO|br-vlan: added primary controller "tcp:127.0.0.1:6633"
2018-10-22T13:55:33.437Z|00415|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:33.677Z|00416|netdev_linux|WARN|error receiving Ethernet packet on eth10: Network is down
2018-10-22T13:55:33.677Z|00417|dpif_netdev|ERR|error receiving data from eth10: Network is down
2018-10-22T13:55:33.679Z|00418|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:33.689Z|00419|bridge|INFO|bridge br-flat1: deleted interface eth8 on port 1
2018-10-22T13:55:33.689Z|00420|dpif_netdev|INFO|Core 42 on numa node 1 assigned port 'dpdk-p0' rx queue 0 (measured processing cycles 103120).
2018-10-22T13:55:33.689Z|00421|dpif_netdev|INFO|Core 18 on numa node 0 assigned port 'vhost-user-1' rx queue 0 (measured processing cycles 0).
2018-10-22T13:55:33.731Z|00422|bridge|INFO|bridge br-flat1: using datapath ID 000026940e0e334d
2018-10-22T13:55:33.731Z|00423|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: disconnecting
2018-10-22T13:55:33.735Z|00424|connmgr|INFO|br-flat1<->tcp:127.0.0.1:6633: 2 flow_mods in the last 0 s (2 adds)
2018-10-22T13:55:33.748Z|00425|bridge|INFO|bridge br-flat1: deleted interface br-flat1 on port 65534
2018-10-22T13:55:33.748Z|00426|bridge|INFO|bridge br-flat1: deleted interface phy-br-flat1 on port 2
2018-10-22T13:55:33.997Z|00427|dpif_netdev|INFO|Core 42 on numa node 1 assigned port 'dpdk-p0' rx queue 0 (measured processing cycles 87660).
2018-10-22T13:55:33.997Z|00428|dpif_netdev|INFO|Core 18 on numa node 0 assigned port 'vhost-user-1' rx queue 0 (measured processing cycles 0).
2018-10-22T13:55:34.266Z|00429|bridge|INFO|bridge br-vlan: deleted interface eth10 on port 1
2018-10-22T13:55:34.267Z|00430|dpif_netdev|INFO|Core 42 on numa node 1 assigned port 'dpdk-p0' rx queue 0 (measured processing cycles 87660).
2018-10-22T13:55:34.267Z|00431|dpif_netdev|INFO|Core 18 on numa node 0 assigned port 'vhost-user-1' rx queue 0 (measured processing cycles 0).
2018-10-22T13:55:34.307Z|00432|bridge|INFO|bridge br-vlan: using datapath ID 00006220d7fae649
2018-10-22T13:55:34.307Z|00433|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: disconnecting
2018-10-22T13:55:34.324Z|00434|bridge|INFO|bridge br-vlan: deleted interface phy-br-vlan on port 2
2018-10-22T13:55:34.324Z|00435|bridge|INFO|bridge br-vlan: deleted interface br-vlan on port 65534
2018-10-22T13:55:34.564Z|00436|dpif_netdev|INFO|Core 42 on numa node 1 assigned port 'dpdk-p0' rx queue 0 (measured processing cycles 87660).
2018-10-22T13:55:34.564Z|00437|dpif_netdev|INFO|Core 18 on numa node 0 assigned port 'vhost-user-1' rx queue 0 (measured processing cycles 0).
2018-10-22T13:55:34.874Z|00438|poll_loop|INFO|Dropped 38 log messages in last 2670 seconds (most recently, 2667 seconds ago) due to excessive rate
2018-10-22T13:55:34.874Z|00439|poll_loop|INFO|wakeup due to [POLLIN] on fd 594 (FIFO pipe:[828052]) at lib/ovs-rcu.c:229 (80% CPU usage)
2018-10-22T13:55:34.874Z|00440|poll_loop|INFO|wakeup due to [POLLIN] on fd 594 (FIFO pipe:[828052]) at lib/ovs-rcu.c:229 (80% CPU usage)
2018-10-22T13:55:34.875Z|00441|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:34.875Z|00442|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:34.875Z|00443|connmgr|INFO|br-int<->tcp:127.0.0.1:6633: 5 flow_mods in the 1 s starting 3 s ago (5 adds)
2018-10-22T13:55:34.875Z|00444|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:34.875Z|00445|poll_loop|INFO|wakeup due to [POLLIN] on fd 10 (NETLINK_ROUTE<->NETLINK_ROUTE) at lib/netlink-socket.c:1331 (80% CPU usage)
2018-10-22T13:55:34.875Z|00446|poll_loop|INFO|wakeup due to [POLLIN] on fd 11 (<->/var/run/openvswitch/db.sock) at lib/stream-fd.c:157 (80% CPU usage)
2018-10-22T13:55:34.881Z|00447|bridge|INFO|bridge br-flat1: added interface br-flat1 on port 65534
2018-10-22T13:55:34.881Z|00448|bridge|INFO|bridge br-flat1: using datapath ID 00008688d47b5149
2018-10-22T13:55:34.881Z|00449|connmgr|INFO|br-flat1: added service controller "punix:/var/run/openvswitch/br-flat1.mgmt"
2018-10-22T13:55:35.134Z|00450|poll_loop|INFO|wakeup due to [POLLIN] on fd 594 (FIFO pipe:[828052]) at lib/ovs-rcu.c:229 (80% CPU usage)
2018-10-22T13:55:35.135Z|00451|poll_loop|INFO|wakeup due to [POLLIN] on fd 594 (FIFO pipe:[828052]) at lib/ovs-rcu.c:229 (80% CPU usage)
2018-10-22T13:55:35.140Z|00452|poll_loop|INFO|wakeup due to [POLLIN] on fd 10 (NETLINK_ROUTE<->NETLINK_ROUTE) at lib/netlink-socket.c:1331 (80% CPU usage)
2018-10-22T13:55:35.140Z|00453|poll_loop|INFO|wakeup due to [POLLIN] on fd 11 (<->/var/run/openvswitch/db.sock) at lib/stream-fd.c:157 (80% CPU usage)
2018-10-22T13:55:35.141Z|00454|poll_loop|INFO|wakeup due to [POLLIN] on fd 594 (FIFO pipe:[828052]) at lib/ovs-rcu.c:229 (80% CPU usage)
2018-10-22T13:55:35.142Z|00455|poll_loop|INFO|wakeup due to [POLLIN] on fd 594 (FIFO pipe:[828052]) at vswitchd/bridge.c:385 (80% CPU usage)
2018-10-22T13:55:35.177Z|00456|bridge|INFO|bridge br-vlan: added interface br-vlan on port 65534
2018-10-22T13:55:35.178Z|00457|bridge|INFO|bridge br-vlan: using datapath ID 00003a70bfb95a40
2018-10-22T13:55:35.178Z|00458|connmgr|INFO|br-vlan: added service controller "punix:/var/run/openvswitch/br-vlan.mgmt"
2018-10-22T13:55:35.433Z|00459|bridge|INFO|bridge br-flat1: added interface eth8 on port 1
2018-10-22T13:55:35.433Z|00460|bridge|INFO|bridge br-flat1: using datapath ID 00003cfdfebcf7a8
2018-10-22T13:55:35.797Z|00461|bridge|INFO|bridge br-vlan: added interface eth10 on port 1
2018-10-22T13:55:35.797Z|00462|bridge|INFO|bridge br-vlan: using datapath ID 00003cfdfebcf548
2018-10-22T13:55:35.835Z|00463|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:35.835Z|00464|rconn|WARN|br-vxlan<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:35.835Z|00465|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: waiting 2 seconds before reconnect
2018-10-22T13:55:35.835Z|00466|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:35.835Z|00467|rconn|WARN|br-int<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:35.835Z|00468|rconn|INFO|br-int<->tcp:127.0.0.1:6633: waiting 2 seconds before reconnect
2018-10-22T13:55:35.836Z|00469|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:35.836Z|00470|rconn|WARN|br-tun<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:35.836Z|00471|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: waiting 2 seconds before reconnect
2018-10-22T13:55:36.673Z|00472|bridge|INFO|bridge br-flat1: deleted interface eth8 on port 1
2018-10-22T13:55:36.675Z|00473|bridge|INFO|bridge br-flat1: using datapath ID 00008688d47b5149
2018-10-22T13:55:36.768Z|00474|bridge|INFO|bridge br-flat1: deleted interface br-flat1 on port 65534
2018-10-22T13:55:37.448Z|00475|bridge|INFO|bridge br-vlan: deleted interface eth10 on port 1
2018-10-22T13:55:37.449Z|00476|bridge|INFO|bridge br-vlan: using datapath ID 00003a70bfb95a40
2018-10-22T13:55:37.463Z|00477|bridge|INFO|bridge br-vlan: deleted interface br-vlan on port 65534
2018-10-22T13:55:38.037Z|00478|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:38.037Z|00479|rconn|WARN|br-vxlan<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:38.037Z|00480|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: waiting 4 seconds before reconnect
2018-10-22T13:55:38.038Z|00481|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:38.038Z|00482|rconn|WARN|br-int<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:38.038Z|00483|rconn|INFO|br-int<->tcp:127.0.0.1:6633: waiting 4 seconds before reconnect
2018-10-22T13:55:38.038Z|00484|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:38.038Z|00485|rconn|WARN|br-tun<->tcp:127.0.0.1:6633: connection failed (Connection refused)
2018-10-22T13:55:38.038Z|00486|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: waiting 4 seconds before reconnect
2018-10-22T13:55:38.044Z|00487|bridge|INFO|bridge br-flat1: added interface br-flat1 on port 65534
2018-10-22T13:55:38.044Z|00488|bridge|INFO|bridge br-flat1: using datapath ID 00008ed18924b545
2018-10-22T13:55:38.044Z|00489|connmgr|INFO|br-flat1: added service controller "punix:/var/run/openvswitch/br-flat1.mgmt"
2018-10-22T13:55:38.351Z|00490|bridge|INFO|bridge br-vlan: added interface br-vlan on port 65534
2018-10-22T13:55:38.352Z|00491|bridge|INFO|bridge br-vlan: using datapath ID 0000627270998843
2018-10-22T13:55:38.352Z|00492|connmgr|INFO|br-vlan: added service controller "punix:/var/run/openvswitch/br-vlan.mgmt"
2018-10-22T13:55:38.616Z|00493|bridge|INFO|bridge br-flat1: added interface eth8 on port 1
2018-10-22T13:55:38.616Z|00494|bridge|INFO|bridge br-flat1: using datapath ID 00003cfdfebcf7a8
2018-10-22T13:55:38.916Z|00495|bridge|INFO|bridge br-vlan: added interface eth10 on port 1
2018-10-22T13:55:38.916Z|00496|bridge|INFO|bridge br-vlan: using datapath ID 00003cfdfebcf548
2018-10-22T13:55:39.889Z|00497|bridge|INFO|bridge br-flat1: deleted interface eth8 on port 1
2018-10-22T13:55:39.890Z|00498|bridge|INFO|bridge br-flat1: using datapath ID 00008ed18924b545
2018-10-22T13:55:39.910Z|00499|bridge|INFO|bridge br-flat1: deleted interface br-flat1 on port 65534
2018-10-22T13:55:40.514Z|00500|bridge|INFO|bridge br-vlan: deleted interface eth10 on port 1
2018-10-22T13:55:40.515Z|00501|bridge|INFO|bridge br-vlan: using datapath ID 0000627270998843
2018-10-22T13:55:40.528Z|00502|bridge|INFO|bridge br-vlan: deleted interface br-vlan on port 65534
2018-10-22T13:55:41.052Z|00503|poll_loop|INFO|Dropped 630 log messages in last 6 seconds (most recently, 1 seconds ago) due to excessive rate
2018-10-22T13:55:41.053Z|00504|poll_loop|INFO|wakeup due to [POLLIN] on fd 594 (FIFO pipe:[828052]) at lib/ovs-rcu.c:229 (51% CPU usage)
2018-10-22T13:55:41.823Z|00505|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:41.823Z|00506|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:41.823Z|00507|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connecting...
2018-10-22T13:55:41.827Z|00508|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:41.827Z|00509|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:41.827Z|00510|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:42.450Z|00511|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:42.450Z|00512|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: continuing to retry connections in the background but suppressing further logging
2018-10-22T13:55:42.450Z|00513|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:42.450Z|00514|rconn|INFO|br-int<->tcp:127.0.0.1:6633: continuing to retry connections in the background but suppressing further logging
2018-10-22T13:55:42.450Z|00515|connmgr|INFO|br-int<->tcp:127.0.0.1:6633: 4 flow_mods in the last 0 s (4 adds)
2018-10-22T13:55:42.450Z|00516|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:42.450Z|00517|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: continuing to retry connections in the background but suppressing further logging
2018-10-22T13:55:49.827Z|00518|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:49.828Z|00519|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:49.828Z|00520|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:50.467Z|00521|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:50.467Z|00522|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connection closed by peer
2018-10-22T13:55:50.467Z|00523|connmgr|INFO|br-int<->tcp:127.0.0.1:6633: 4 flow_mods in the last 0 s (4 adds)
2018-10-22T13:55:50.467Z|00524|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connection closed by peer

From fichera.sil at gmail.com  Mon Oct 22 17:16:58 2018
From: fichera.sil at gmail.com (Silvia Fichera)
Date: Mon, 22 Oct 2018 19:16:58 +0200
Subject: [Openstack] ovs-ofctl: br-int is not a bridge or a socket - compute
	nodes
Message-ID: <CAEFdjR0-sm=Nfs+PETgrEZmq0Mm0xzuZUp4eQzKsL9VP16kwdg@mail.gmail.com>

Hi all,
I have deployed a multi node setup with devstack rocky.
I'm also using the SFC plugin.
I want to check the flows in the br-int of the compute node doing
sudo ovs-ofctl dump-flows br-int -O OpenFlow13  table=0
but I have this error:
ovs-ofctl: br-int is not a bridge or a socket

Do you know why?
-- 
Silvia Fichera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181022/f3d9e132/attachment.html>

From giorgis at acmac.uoc.gr  Tue Oct 23 09:29:53 2018
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Tue, 23 Oct 2018 12:29:53 +0300
Subject: [Openstack] Recover Controller Node
Message-ID: <f254294a01a5d133f2658b937d4ce729@acmac.uoc.gr>

 Dear all,

 the HDD on my OpenStack controller has failed and I would like to know 
 what is the best way to recover some basic controller functions assuming 
 that I can get some of the data from it.

 Let me give you some information about the installation's background 
 and what I would like to do (ideally).
 First of all let me say that this is an old OpenStack installation with 
 Icehouse on two bare metal nodes, one controller and one compute. Since 
 it was the controller's HDD that failed all my VMs are still up and 
 running but I have no way to perform tasks on them e.g. snapshot, 
 terminate, launch new etc.

 So I am wondering what would be the best possible scenario and approach 
 in order to recover some functionality on them. What I would like 
 ideally to do is to be able to snapshot a couple of already running VMs 
 and then move the snapshots to a new installation that I am going to 
 deploy. Besides the snapshots I don't need anything else from the 
 existing installation.

 The controller's HDD is not completely dead which means that I can 
 browse it and I can try to copy some files (e.g. older useful snapshots) 
 but clonning it to a new one wasn't successful (clonning worked but 
 couldn't boot). I can sure try to resurrect the DB from it and besides 
 that I would also need obviously all the "conf" files.

 Assuming that I can get these from the failed HDD what would be my next 
 steps? Try on a different HDD to set the old environment from scratch 
 using the "saved" configurations? Would it be better if I moved all 
 required services, DB etc. to the compute node in order to perform the 
 maintenance on a single node? How can I do that? Should it be better if 
 I just go directly to a much newer version and how can I get the running 
 VMs from that? Any ideas what else I might need besides the DB and the 
 "conf" files?

 Looking forward for your answers!

 Best regards,

 G.


From lbragstad at gmail.com  Tue Oct 23 10:14:43 2018
From: lbragstad at gmail.com (Lance Bragstad)
Date: Tue, 23 Oct 2018 05:14:43 -0500
Subject: [Openstack] Pike: Keystone setup problem (in Docker
	container...)
In-Reply-To: <CAE6oFcGLBqjMkyc6by7nZEqvG_VCc5a0BvQxEzCCE=XN5SH36w@mail.gmail.com>
References: <285a4fb8-f8e0-453e-04a9-9fda1acaee24@meduniwien.ac.at>
 <CAE6oFcGLBqjMkyc6by7nZEqvG_VCc5a0BvQxEzCCE=XN5SH36w@mail.gmail.com>
Message-ID: <CAE6oFcE=yPQ7_g9409jdVZNv_dOGoZxz3DU1b9yY6aDKK1NA_Q@mail.gmail.com>

Add the ML back into the thread.

On Tue, Oct 23, 2018 at 5:13 AM Lance Bragstad <lbragstad at gmail.com> wrote:

>
> On Tue, Oct 9, 2018 at 9:49 AM Matthias Leopold <
> matthias.leopold at meduniwien.ac.at> wrote:
>
>> Hi,
>>
>> I'm trying to setup Cinder as a standalone service with Docker using the
>> blockbox system (contrib/blockbox in the Cinder source distribution). I
>> was inspired by this manual:
>> https://thenewstack.io/deploying-cinder-stand-alone-storage-service/.
>>
>> This works quite well with Cinder’s noauth option as described above.
>> Now i want/have to add Keystone to the mix. I built the Keystone image
>> and added a custom init script to initialize Keystone when fired up and
>> a certain environment is set. For this i followed instructions from
>> https://docs.openstack.org/keystone/pike/install/keystone-install-rdo.html
>> .
>>
>> This works to the point where "keystone-manage bootstrap" is called.
>> This fails with:
>>
>> CRITICAL keystone [req-45247f41-0e4f-4cc7-8bb8-60c3793489b9 - - - - -]
>> Unhandled error: TypeError: unpackb() got an unexpected keyword argument
>> 'raw'
>>
>
> This feels like a dependency issue. Are you able to share more of the
> trace? The method in question, unpackb() is a part of msgpack, which is a
> library that keystone uses to serialize token payloads before encrypting
> them.
>
> It could be that your version of msgpack isn't up-to-date.
>
>
>>
>> Can anybody tell me what's wrong?
>>
>> Of course my setup is rather special so I'll mention some more details:
>> Docker host system: CentOS 7
>> Docker version: 18.06.1-ce, build e68fc7a
>> Keystone branch: stable/pike
>> Platform (for docker images): centos:7
>>
>> I additionally rolled the python2-pyasn1 package into the Keystone
>> image, but that didn't help. The "keystone" database in the "mariadb"
>> container is initialized and accessible from the "keystone" container, i
>> checked that.
>>
>> I know this is a rather exotic case, but maybe someone recognizes the
>> obvious problem. I'm not an OpenStack expert (want to use Cinder for
>> oVirt).
>>
>> thx
>> Matthias
>>
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181023/518de2da/attachment.html>

From adriancampos at teachelp.com  Thu Oct 25 10:59:58 2018
From: adriancampos at teachelp.com (=?iso-8859-1?Q?Adri=E1n_Campos_Garrido?=)
Date: Thu, 25 Oct 2018 10:59:58 +0000
Subject: [Openstack] Working on a Android app for Openstack client
Message-ID: <BN6PR13MB14734FF0D3983D6879434D65A5F70@BN6PR13MB1473.namprd13.prod.outlook.com>

Hello,

Since months agos, I am working on a Openstack Client application for Android whose objective is to managa your own openstack cloud or you instances if your are a client from a Openstack Cloud Provider.

Last version was 0.7 and i think that basic bugs for connection and starting manage is fixed.
In fact in last version the changelog is:

Fix problem with AUTH on new releases.
Fix instances hostname for users without permissions.
Fix all problems when there isn't any data.
Re-desing interface to use all screen.
Change some logo to use Openstack logo instead of stars logo.

It's a fork from an old project which it's called stackerz, I made some arrangements on login to adapt it for new Keystone V3 and some improvements on calls to certain Openstack API calls.

I would like to to ask to list if you see an useful project to continue or maybe not.

https://play.google.com/store/apps/details?id=com.alefnode.openstack&hl=en_US

Regards,
Adrian Campos

[https://lh3.googleusercontent.com/XBT2ArGBP5nAbG0RRySrJPcv-koCPYgxfHzDeeUVgcMKG9x8ZuYHdByQGGY71Yjifw]<https://play.google.com/store/apps/details?id=com.alefnode.openstack&hl=en_US>

Openstack Client - Apps on Google Play<https://play.google.com/store/apps/details?id=com.alefnode.openstack&hl=en_US>
Openstack client for Android. Tested on Openstack Queens (2018.02) and Openstack Pike (2017.08) With this application you can manage all your openstack platform. - Servers - Networks - Subnets - Security Groups - Flavors This is a beta release and only for Keystone V3 authentication.
play.google.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181025/6e6a7ead/attachment.html>

From alex at privacysystems.eu  Thu Oct 25 12:06:37 2018
From: alex at privacysystems.eu (Alexandru Sorodoc)
Date: Thu, 25 Oct 2018 15:06:37 +0300
Subject: [Openstack] [Pike][Neutron] L3 metering with DVR doesn't work
Message-ID: <9ea77aca-0878-20b2-da0c-537b47e8b3f0@privacysystems.eu>

Hello,

I'm trying to set up metering for neutron in Pike. I tested it with a
centralized router and it works, but when I try with a distributed router it
doesn't record any usage samples. I have one compute node and one 
network node
and I've created an instance with a floating ip.

openstack router show public-router2
+-------------------------+----------------------------------------------------+
| Field                   | 
Value                                              |
+-------------------------+----------------------------------------------------+
| admin_state_up          | 
UP                                                 |
| availability_zone_hints 
|                                                    |
| availability_zones      | 
nova                                               |
| created_at              | 
2018-10-05T12:07:32Z                               |
| description |                                                    |
| distributed             | 
True                                               |
| external_gateway_info   | {"network_id": 
"b96473ce-                          |
|                         | 94f6-464f-a703-5285fb8ff3d3", "enable_snat": 
true, |
|                         | "external_fixed_ips": 
[{"subnet_id":               |
|                         | 
"6c08c3d9-7df1-4bec-b847-19f80b9d1764",            |
|                         | "ip_address": 
"192.168.252.102"}]}                 |
| flavor_id               | 
None                                               |
| ha                      | 
False                                              |
| id                      | 
37c1794b-58d1-4d0d-b34b-944ca411b86b               |
| name                    | 
public-router2                                     |
| project_id              | 
fe203109e67f4e39b066c9529f9fc35d                   |
| revision_number         | 
5                                                  |
| routes |                                                    |
| status                  | 
ACTIVE                                             |
| tags |                                                    |
| updated_at              | 
2018-10-05T12:09:36Z                               |
+-------------------------+----------------------------------------------------+

openstack network agent list
+-----------+------------+-----------+-------------------+-------+-------+--------------+
| ID        | Agent Type | Host      | Availability Zone | Alive | State 
| Binary       |
+-----------+------------+-----------+-------------------+-------+-------+--------------+
| 14b9ea75- | L3 agent   | compute1. | nova | :-)   | UP    | neutron-l3-a |
| 1dc1-4e37 |            | localdoma | |       |       | gent         |
| -a2b0-508 |            | in        | |       |       |              |
| 3d336916d |            |           | |       |       |              |
| 26139ec1- | Metering   | compute1. | None | :-)   | UP    | neutron-     |
| f4f9-4bb3 | agent      | localdoma | |       |       | metering-    |
| -aebb-c35 |            | in        | |       |       | agent        |
| 3a36ed79c |            |           | |       |       |              |
| 2a54971f- | DHCP agent | network1. | nova | :-)   | UP    | neutron-     |
| 9849-4ed2 |            | localdoma | |       |       | dhcp-agent   |
| -b009-00e |            | in        | |       |       |              |
| 45eb4d255 |            |           | |       |       |              |
| 443c0b49- | Open       | compute1. | None | :-)   | UP    | neutron-     |
| 4484-44d2 | vSwitch    | localdoma | |       |       | openvswitch- |
| -a704-32a | agent      | in        | |       |       | agent        |
| 92ffe6982 |            |           | |       |       |              |
| 5d00a219  | L3 agent   | network1. | nova | :-)   | UP    | neutron-vpn- |
| -abce-    |            | localdoma | |       |       | agent        |
| 48ca-     |            | in        | |       |       |              |
| ba1e-d962 |            |           | |       |       |              |
| 01bd7de3  |            |           | |       |       |              |
| bc3458b4  | Open       | network1. | None | :-)   | UP    | neutron-     |
| -250e-    | vSwitch    | localdoma | |       |       | openvswitch- |
| 4adf-90e0 | agent      | in        | |       |       | agent        |
| -110a1a7f |            |           | |       |       |              |
| 6ccb      |            |           | |       |       |              |
| c29f9da8- | Metering   | network1. | None | :-)   | UP    | neutron-     |
| ca58-4a11 | agent      | localdoma | |       |       | metering-    |
| -b500-a25 |            | in        | |       |       | agent        |
| 3f820808e |            |           | |       |       |              |
| cdce667d- | Metadata   | network1. | None | :-)   | UP    | neutron-     |
| faa4      | agent      | localdoma | |       |       | metadata-    |
| -49ed-    |            | in        | |       |       | agent        |
| 83ee-e0e5 |            |           | |       |       |              |
| a352d482  |            |           | |       |       |              |
| cf5ae104- | Metadata   | compute1. | None | :-)   | UP    | neutron-     |
| 49d7-4c85 | agent      | localdoma | |       |       | metadata-    |
| -a252-cc5 |            | in        | |       |       | agent        |
| 9a9a12789 |            |           | |       |       |              |
+-----------+------------+-----------+-------------------+-------+-------+--------------+

If I check the node on which my distributed router is running it tells 
me that
it's running on the network node:

neutron l3-agent-list-hosting-router 37c1794b-58d1-4d0d-b34b-944ca411b86b
+--------------------------------------+----------------------+----------------+-------+----------+
| id                                   | host                 | 
admin_state_up | alive | ha_state |
+--------------------------------------+----------------------+----------------+-------+----------+
| 5d00a219-abce-48ca-ba1e-d96201bd7de3 | network1.localdomain | 
True           | :-)   |          |
+--------------------------------------+----------------------+----------------+-------+----------+

If I check the iptable rules for the router on the compute and network 
nodes by running:

ip netns exec qrouter-37c1794b-58d1-4d0d-b34b-944ca411b86b iptables -nv -L

I see that compute1 records the traffic while network1 doesn't. Also, I 
did some
debugging and found out that the metering agent on compute1 receives an 
empty
list of routers when querying the routers that it should monitor.

Source:

https://github.com/openstack/neutron/blob/stable/pike/neutron/services/metering/agents/metering_agent.py#L177-L189

https://github.com/openstack/neutron/blob/stable/pike/neutron/db/metering/metering_rpc.py#L33-L57

I think this is because the router is running on network1. Why is it 
running on
network1 and why does it seem that the l3 agent on compute1 does the actual
routing?

Thanks,
Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181025/c01ec34c/attachment.html>

From abogott at wikimedia.org  Thu Oct 25 13:45:40 2018
From: abogott at wikimedia.org (Andrew Bogott)
Date: Thu, 25 Oct 2018 08:45:40 -0500
Subject: [Openstack] Server names vs. DNS: Can I restrict server names to
	match a regex?
Message-ID: <9eeb9949-7409-8cfe-3109-0d7ab47d1a19@gmail.com>

     A fair bit of my setup uses service names for automatic naming 
elsewhere.  For example, we have NFS mounts like /path/to/<servername> 
and automatic DNS like <servername>.example.org

     Of course, if a user is determined to to create a less useful 
instance, they can create one with a name like "...."  or "../../.." 
which will result in hilarity.

     I'm sure that I'm not the only one who regards a server name as 
useful for naming other resources.  What solutions do you use? Is there 
a way to tell nova or Horizon to restrict server names to a given pattern?



From adhi.pri at gmail.com  Fri Oct 26 04:29:27 2018
From: adhi.pri at gmail.com (Adhi Priharmanto)
Date: Fri, 26 Oct 2018 11:29:27 +0700
Subject: [Openstack] non public glance image can seen by all tenant
Message-ID: <CAHaOoEW1+GRutjjUuK=yfYvf8nhsY5DM3eK=QY8A25bc14JaAw@mail.gmail.com>

Hi,
I have setup rocky release at my openstack lab, now all of tenant (user)
can see non-public glance image create by another tenant (user)

here is my glance policy.json :

> {
>     "context_is_admin":  "role:admin",
>     "default": "role:admin",
>     "add_image": "",
>     "delete_image": "",
>     "get_image": "",
>     "get_images": "",
>     "modify_image": "",
>     "publicize_image": "role:admin",
>     "communitize_image": "",
>     "copy_from": "",
>     "download_image": "",
>     "upload_image": "",
>     "delete_image_location": "",
>     "get_image_location": "",
>     "set_image_location": "",
>     "add_member": "",
>     "delete_member": "",
>     "get_member": "",
>     "get_members": "",
>     "modify_member": "",
>     "manage_image_cache": "role:admin",
>     "get_task": "",
>     "get_tasks": "",
>     "add_task": "",
>     "modify_task": "",
>     "tasks_api_access": "role:admin",
>     "deactivate": "",
>     "reactivate": "",
>     "get_metadef_namespace": "",
>     "get_metadef_namespaces":"",
>     "modify_metadef_namespace":"",
>     "add_metadef_namespace":"",
>     "get_metadef_object":"",
>     "get_metadef_objects":"",
>     "modify_metadef_object":"",
>     "add_metadef_object":"",
>     "list_metadef_resource_types":"",
>     "get_metadef_resource_type":"",
>     "add_metadef_resource_type_association":"",
>     "get_metadef_property":"",
>     "get_metadef_properties":"",
>     "modify_metadef_property":"",
>     "add_metadef_property":"",
>     "get_metadef_tag":"",
>     "get_metadef_tags":"",
>     "modify_metadef_tag":"",
>     "add_metadef_tag":"",
>     "add_metadef_tags":""
> }


any advice how to fix this ?


-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi
<http://about.me/a_dhi?promo=email_sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181026/bd982693/attachment.html>

From ttml at fastmail.com  Fri Oct 26 09:50:34 2018
From: ttml at fastmail.com (Tushar Tyagi)
Date: Fri, 26 Oct 2018 15:20:34 +0530
Subject: [Openstack] IO flow on multi-node setup
Message-ID: <1540547434.137167.1555356160.3C4D4D62@webmail.messagingengine.com>

Hello,

I have a requirement to create a multi node setup with Controller, Compute and Storage nodes on different machines. 

In case I create a virtual machine on the compute node, it's going to be provisioned by the Controller node and the storage is going to be provided by the Storage node. In case I require any more volumes, the same are going to be provisioned by the Storage node, and then can be attached to the VM.

I wanted to know will the IO requests from Compute to Storage node go via Controller or will these be direct? In case it's the former, how much performance impact will be there due to the added redirection?

Thanks,
Tushar 


From berndbausch at gmail.com  Fri Oct 26 12:18:26 2018
From: berndbausch at gmail.com (Bernd Bausch)
Date: Fri, 26 Oct 2018 21:18:26 +0900
Subject: [Openstack] IO flow on multi-node setup
In-Reply-To: <1540547434.137167.1555356160.3C4D4D62@webmail.messagingengine.com>
References: <1540547434.137167.1555356160.3C4D4D62@webmail.messagingengine.com>
Message-ID: <8d9af54c-b0e6-8cf5-e457-32fcc47f40f3@gmail.com>

Volume I/O won't flow through the controller. The LVM reference driver,
for example, sets up an iSCSI target on the storage node, which the
compute node then imports. The NFS driver has the compute node mount the
exported filesystem. Depending on the driver, I/O may even flow directly
between an iSCSI or fibre-channel disk array and the compute node.

What storage backend(s) are you deploying?

On 10/26/2018 6:50 PM, Tushar Tyagi wrote:
> Hello,
>
> I have a requirement to create a multi node setup with Controller, Compute and Storage nodes on different machines. 
>
> In case I create a virtual machine on the compute node, it's going to be provisioned by the Controller node and the storage is going to be provided by the Storage node. In case I require any more volumes, the same are going to be provisioned by the Storage node, and then can be attached to the VM.
>
> I wanted to know will the IO requests from Compute to Storage node go via Controller or will these be direct? In case it's the former, how much performance impact will be there due to the added redirection?
>
> Thanks,
> Tushar 
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181026/aa2777d6/attachment.sig>

From ttml at fastmail.com  Fri Oct 26 13:03:30 2018
From: ttml at fastmail.com (Tushar Tyagi)
Date: Fri, 26 Oct 2018 18:33:30 +0530
Subject: [Openstack] IO flow on multi-node setup
In-Reply-To: <8d9af54c-b0e6-8cf5-e457-32fcc47f40f3@gmail.com>
References: <1540547434.137167.1555356160.3C4D4D62@webmail.messagingengine.com>
 <8d9af54c-b0e6-8cf5-e457-32fcc47f40f3@gmail.com>
Message-ID: <1540559010.198597.1555525240.5ABEA474@webmail.messagingengine.com>

I am using Rocky release and configuring for NVMe backend with LVM. Can you please tell me how this one might flow, or redirect me to the documentation?
I have not been able to found much documentation regarding this.

-- 
  Tushar Tyagi
  ttml at fastmail.com

On Fri, Oct 26, 2018, at 17:48, Bernd Bausch wrote:
> Volume I/O won't flow through the controller. The LVM reference driver,
> for example, sets up an iSCSI target on the storage node, which the
> compute node then imports. The NFS driver has the compute node mount the
> exported filesystem. Depending on the driver, I/O may even flow directly
> between an iSCSI or fibre-channel disk array and the compute node.
> 
> What storage backend(s) are you deploying?
> 
> On 10/26/2018 6:50 PM, Tushar Tyagi wrote:
> > Hello,
> >
> > I have a requirement to create a multi node setup with Controller, Compute and Storage nodes on different machines. 
> >
> > In case I create a virtual machine on the compute node, it's going to be provisioned by the Controller node and the storage is going to be provided by the Storage node. In case I require any more volumes, the same are going to be provisioned by the Storage node, and then can be attached to the VM.
> >
> > I wanted to know will the IO requests from Compute to Storage node go via Controller or will these be direct? In case it's the former, how much performance impact will be there due to the added redirection?
> >
> > Thanks,
> > Tushar 
> >
> > _______________________________________________
> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to     : openstack at lists.openstack.org
> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)


From fungi at yuggoth.org  Fri Oct 26 13:20:50 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 26 Oct 2018 13:20:50 +0000
Subject: [Openstack] non public glance image can seen by all tenant
In-Reply-To: <CAHaOoEW1+GRutjjUuK=yfYvf8nhsY5DM3eK=QY8A25bc14JaAw@mail.gmail.com>
References: <CAHaOoEW1+GRutjjUuK=yfYvf8nhsY5DM3eK=QY8A25bc14JaAw@mail.gmail.com>
Message-ID: <20181026132050.nan53w2i4ihknu52@yuggoth.org>

On 2018-10-26 11:29:27 +0700 (+0700), Adhi Priharmanto wrote:
> I have setup rocky release at my openstack lab, now all of tenant
> (user) can see non-public glance image create by another tenant
> (user)
[...]

This sounds very similar to https://launchpad.net/bugs/1799588 which
the Glance team has been asked to look into. See also the rather
lengthy troubleshooting discussion on the Operators ML starting
here:

http://lists.openstack.org/pipermail/openstack-operators/2018-October/016039.html

-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181026/96f792c7/attachment.sig>

From openstack at hauschild.it  Fri Oct 26 14:15:46 2018
From: openstack at hauschild.it (Hartwig Hauschild)
Date: Fri, 26 Oct 2018 16:15:46 +0200
Subject: [Openstack] missing ovs flows and extra interfaces in pike
In-Reply-To: <eec163a5-ecfc-8c18-1155-a07a2e84f926@gmail.com>
References: <20181019133242.xbmibiqh6wwiwuzm@alle-irre.de>
 <eec163a5-ecfc-8c18-1155-a07a2e84f926@gmail.com>
Message-ID: <20181026141545.v63fvxrfjmtbibyu@alle-irre.de>

Hi, 

How are you calculating which flows you're missing?

We thought we're missing the flow for "if you're looking for this MAC go
this way", but it turned out that what's actually missing is a bunch of
interfaces on the multicast-flow for the vlan that we're investigating.

Is that what you're seeing as well?

Cheers, 

Hardy

Am 19.10.2018 schrieb Fabian Zimmermann:
> Hi,
> 
> we see something similar. We are running ovs, vxlan - but legacy routers
> directly on hvs without any network nodes.
> 
> Currently we didnt find a way to fix or reproduce the issue. We just wrote a
> small script which calcuates which flow should be on with hv and if
> something is missing -> send an alert.
> 
> The operator will then restart the suitable ovs-agent and everything is
> working again.
> 
> We also found out, that the problem is gone as soon as we disable l2pop, but
> this is not possible if we (as you already did) switch to dvr.
> 
> So at the moment we plan to disable l2pop and move our routers back to some
> network nodes.
> 
> I would be glad if someone is able to reproduce or even better - fix the
> issue.
> 
>  Fabian
> 
> Am 19.10.18 um 15:32 schrieb Hartwig Hauschild:
> > Hi,
> > 
> > [ I have no idea how much of the following information is necessary ]
> > 
> > We're running Openstack Pike, deployed with Openstack-Ansible 16.0.5.
> > The system is running on a bunch of compute-nodes and three combined
> > network/management-nodes, we're using OVS, DVR and VXLAN for networking.
> > 
> > The DVRs are set up with snat disabled, that's handled by different
> > systems.
> > 
> > We have recently noticed that we don't have north-south-connectivity in
> > a couple of qdhcp-netns and after a weeks worth of debugging it boils
> > down to missing OVS-flows on br-tun that should be directing the
> > northbound traffic at the node with the live snat-netns.
> > 
> > We also noticed that while every node has the ports for the
> > qdhcp-netns that belong on the node we also have a couple of taps and
> > flows for ports that are on other nodes.
> > 
> > To make that a bit clearer:
> > If you have network A with dhcp-services F, G, H we found that the ip
> > netns containing the dnsmasq for F, G, H are on nodes 1, 2, 3
> > respectively, but node 1 would also have the tap-interface and flows for
> > G on br-int dangeling freely without any netns.
> > 
> > Is there a simple explanation for this and maybe even a fix?
> > 
> > What we found so far seems to suggest we should either restart the
> > management-nodes or the neutron-agent-containers or at least stop, clean
> > and start ovs and neutron-openvswitch-agent inside the containers.
> > 
> > Is it possible to somehow redeploy or validate the flows from neutron to
> > make sure that everything is consistent apart from restarts?
> > 
> > 


From berndbausch at gmail.com  Fri Oct 26 14:42:12 2018
From: berndbausch at gmail.com (Bernd Bausch)
Date: Fri, 26 Oct 2018 23:42:12 +0900
Subject: [Openstack] IO flow on multi-node setup
In-Reply-To: <1540559010.198597.1555525240.5ABEA474@webmail.messagingengine.com>
References: <1540547434.137167.1555356160.3C4D4D62@webmail.messagingengine.com>
 <8d9af54c-b0e6-8cf5-e457-32fcc47f40f3@gmail.com>
 <1540559010.198597.1555525240.5ABEA474@webmail.messagingengine.com>
Message-ID: <8a8cf150-b1c1-eb58-f729-3b491f78fdda@gmail.com>

You configure an LVM volume group for each Cinder backend. A CInder
volume on that backend corresponds to an LVM volume in that volume
group. The LVM volume is exposed as an iSCSI target, usually via LIO,
but I believe this is configurable. The compute node uses /iscsiadm /to
import that volume as a SCSI device and connects that device to the VM.

I don't know if this is documented anywhere, but it's easy and fun to
explore. On the storage node, use LVM commands to look into volume
groups and volumes, and the /tgtadm /command to check targets. On the
compute node, list all SCSI disks, use /iscsiadm -m session /to check
iSCSI sessions, and use /virsh domblklist /and /virsh edit /(assuming
your hypervisor is libvirt-controlled) to confirm that the iSCSI LUN is
connected to the VM.

On 10/26/2018 10:03 PM, Tushar Tyagi wrote:
> I am using Rocky release and configuring for NVMe backend with LVM. Can you please tell me how this one might flow, or redirect me to the documentation?
> I have not been able to found much documentation regarding this.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181026/bdc6b54f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181026/bdc6b54f/attachment.sig>

From haleyb.dev at gmail.com  Fri Oct 26 18:49:49 2018
From: haleyb.dev at gmail.com (Brian Haley)
Date: Fri, 26 Oct 2018 14:49:49 -0400
Subject: [Openstack] [Pike][Neutron] L3 metering with DVR doesn't work
In-Reply-To: <9ea77aca-0878-20b2-da0c-537b47e8b3f0@privacysystems.eu>
References: <9ea77aca-0878-20b2-da0c-537b47e8b3f0@privacysystems.eu>
Message-ID: <e8be927b-0cd0-5dfc-5936-589fd1bb135e@gmail.com>

On 10/25/2018 08:06 AM, Alexandru Sorodoc wrote:
> Hello,
> 
> I'm trying to set up metering for neutron in Pike. I tested it with a
> centralized router and it works, but when I try with a distributed router it
> doesn't record any usage samples. I have one compute node and one 
> network node
> and I've created an instance with a floating ip.

The metering agent isn't very well maintained, and I don't see any open 
bugs similar to this issue.  The only thing I can remember is this 
abandoned change regarding traffic counters for DVR routers - 
https://review.openstack.org/#/c/486493/ but there was no follow-on from 
the author.

The best thing to do would be to try and reproduce it on the master 
branch (or Rocky) and file a bug.

 > I think this is because the router is running on network1. Why is it
 > running on
 > network1 and why does it seem that the l3 agent on compute1 does the 
actual
 > routing?

The compute node will do all the routing when a floating IP is 
associated, the router on network1 is for default snat traffic when 
there is no floating IP and the instance tries to communicate out the 
external network.

-Brian

> 
> openstack router show public-router2
> +-------------------------+----------------------------------------------------+
> | Field                   | 
> Value                                              |
> +-------------------------+----------------------------------------------------+
> | admin_state_up          | 
> UP                                                 |
> | availability_zone_hints 
> |                                                    |
> | availability_zones      | 
> nova                                               |
> | created_at              | 
> 2018-10-05T12:07:32Z                               |
> | description |                                                    |
> | distributed             | 
> True                                               |
> | external_gateway_info   | {"network_id": 
> "b96473ce-                          |
> |                         | 94f6-464f-a703-5285fb8ff3d3", "enable_snat": 
> true, |
> |                         | "external_fixed_ips": 
> [{"subnet_id":               |
> |                         | 
> "6c08c3d9-7df1-4bec-b847-19f80b9d1764",            |
> |                         | "ip_address": 
> "192.168.252.102"}]}                 |
> | flavor_id               | 
> None                                               |
> | ha                      | 
> False                                              |
> | id                      | 
> 37c1794b-58d1-4d0d-b34b-944ca411b86b               |
> | name                    | 
> public-router2                                     |
> | project_id              | 
> fe203109e67f4e39b066c9529f9fc35d                   |
> | revision_number         | 
> 5                                                  |
> | routes |                                                    |
> | status                  | 
> ACTIVE                                             |
> | tags |                                                    |
> | updated_at              | 
> 2018-10-05T12:09:36Z                               |
> +-------------------------+----------------------------------------------------+
> 
> openstack network agent list
> +-----------+------------+-----------+-------------------+-------+-------+--------------+
> | ID        | Agent Type | Host      | Availability Zone | Alive | State 
> | Binary       |
> +-----------+------------+-----------+-------------------+-------+-------+--------------+
> | 14b9ea75- | L3 agent   | compute1. | nova | :-)   | UP    | neutron-l3-a |
> | 1dc1-4e37 |            | localdoma | |       |       | gent         |
> | -a2b0-508 |            | in        | |       |       |              |
> | 3d336916d |            |           | |       |       |              |
> | 26139ec1- | Metering   | compute1. | None | :-)   | UP    | neutron-     |
> | f4f9-4bb3 | agent      | localdoma | |       |       | metering-    |
> | -aebb-c35 |            | in        | |       |       | agent        |
> | 3a36ed79c |            |           | |       |       |              |
> | 2a54971f- | DHCP agent | network1. | nova | :-)   | UP    | neutron-     |
> | 9849-4ed2 |            | localdoma | |       |       | dhcp-agent   |
> | -b009-00e |            | in        | |       |       |              |
> | 45eb4d255 |            |           | |       |       |              |
> | 443c0b49- | Open       | compute1. | None | :-)   | UP    | neutron-     |
> | 4484-44d2 | vSwitch    | localdoma | |       |       | openvswitch- |
> | -a704-32a | agent      | in        | |       |       | agent        |
> | 92ffe6982 |            |           | |       |       |              |
> | 5d00a219  | L3 agent   | network1. | nova | :-)   | UP    | neutron-vpn- |
> | -abce-    |            | localdoma | |       |       | agent        |
> | 48ca-     |            | in        | |       |       |              |
> | ba1e-d962 |            |           | |       |       |              |
> | 01bd7de3  |            |           | |       |       |              |
> | bc3458b4  | Open       | network1. | None | :-)   | UP    | neutron-     |
> | -250e-    | vSwitch    | localdoma | |       |       | openvswitch- |
> | 4adf-90e0 | agent      | in        | |       |       | agent        |
> | -110a1a7f |            |           | |       |       |              |
> | 6ccb      |            |           | |       |       |              |
> | c29f9da8- | Metering   | network1. | None | :-)   | UP    | neutron-     |
> | ca58-4a11 | agent      | localdoma | |       |       | metering-    |
> | -b500-a25 |            | in        | |       |       | agent        |
> | 3f820808e |            |           | |       |       |              |
> | cdce667d- | Metadata   | network1. | None | :-)   | UP    | neutron-     |
> | faa4      | agent      | localdoma | |       |       | metadata-    |
> | -49ed-    |            | in        | |       |       | agent        |
> | 83ee-e0e5 |            |           | |       |       |              |
> | a352d482  |            |           | |       |       |              |
> | cf5ae104- | Metadata   | compute1. | None | :-)   | UP    | neutron-     |
> | 49d7-4c85 | agent      | localdoma | |       |       | metadata-    |
> | -a252-cc5 |            | in        | |       |       | agent        |
> | 9a9a12789 |            |           | |       |       |              |
> +-----------+------------+-----------+-------------------+-------+-------+--------------+
> 
> If I check the node on which my distributed router is running it tells 
> me that
> it's running on the network node:
> 
> neutron l3-agent-list-hosting-router 37c1794b-58d1-4d0d-b34b-944ca411b86b
> +--------------------------------------+----------------------+----------------+-------+----------+
> | id                                   | host                 | 
> admin_state_up | alive | ha_state |
> +--------------------------------------+----------------------+----------------+-------+----------+
> | 5d00a219-abce-48ca-ba1e-d96201bd7de3 | network1.localdomain | 
> True           | :-)   |          |
> +--------------------------------------+----------------------+----------------+-------+----------+
> 
> If I check the iptable rules for the router on the compute and network 
> nodes by running:
> 
> ip netns exec qrouter-37c1794b-58d1-4d0d-b34b-944ca411b86b iptables -nv -L
> 
> I see that compute1 records the traffic while network1 doesn't. Also, I 
> did some
> debugging and found out that the metering agent on compute1 receives an 
> empty
> list of routers when querying the routers that it should monitor.
> 
> Source:
> 
> https://github.com/openstack/neutron/blob/stable/pike/neutron/services/metering/agents/metering_agent.py#L177-L189
> 
> https://github.com/openstack/neutron/blob/stable/pike/neutron/db/metering/metering_rpc.py#L33-L57
> 
> I think this is because the router is running on network1. Why is it 
> running on
> network1 and why does it seem that the l3 agent on compute1 does the actual
> routing?
> 
> Thanks,
> Alex
> 
> 
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 



From adhi.pri at gmail.com  Sat Oct 27 08:36:12 2018
From: adhi.pri at gmail.com (Adhi Priharmanto)
Date: Sat, 27 Oct 2018 15:36:12 +0700
Subject: [Openstack] non public glance image can seen by all tenant
In-Reply-To: <20181026132050.nan53w2i4ihknu52@yuggoth.org>
References: <CAHaOoEW1+GRutjjUuK=yfYvf8nhsY5DM3eK=QY8A25bc14JaAw@mail.gmail.com>
 <20181026132050.nan53w2i4ihknu52@yuggoth.org>
Message-ID: <CAHaOoEXnaneSyLbWKZrXtLTjciifsP7zg2KNC+A0dG2QQ=ZsVA@mail.gmail.com>

Great,

Thanks Jeremy for pointing me in the right direction

On Fri, Oct 26, 2018 at 8:26 PM Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2018-10-26 11:29:27 +0700 (+0700), Adhi Priharmanto wrote:
> > I have setup rocky release at my openstack lab, now all of tenant
> > (user) can see non-public glance image create by another tenant
> > (user)
> [...]
>
> This sounds very similar to https://launchpad.net/bugs/1799588 which
> the Glance team has been asked to look into. See also the rather
> lengthy troubleshooting discussion on the Operators ML starting
> here:
>
>
> http://lists.openstack.org/pipermail/openstack-operators/2018-October/016039.html
>
> --
> Jeremy Stanley
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>


-- 
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi
<http://about.me/a_dhi?promo=email_sig>
+62-812-82121584
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181027/0f6c572c/attachment.html>

From ppiyakk2 at printf.kr  Mon Oct 29 13:07:08 2018
From: ppiyakk2 at printf.kr (SeongSoo Cho)
Date: Mon, 29 Oct 2018 22:07:08 +0900
Subject: [Openstack] [Swift] PUT Object performance problem
Message-ID: <CAL2V8z72VbjUCaeStkQyxqMnvB_QmiSHAS5H8adBwiCbBT5oeg@mail.gmail.com>

Hello, All

I have a terrible problem with object server.
Here is the case.
1. User upload an object to proxy-server
2. Proxy server try to connect with object-server
3. If one of object-server is slow to respond, proxy-server is waiting for
response.
  3.1 While waiting for response, proxy-server can't do anything
4. So, The response of client request will be delayed.

In my opinion, this code seems to be a problem
(
https://github.com/openstack/swift/blob/stable/rocky/swift/proxy/controllers/obj.py#L1734
)

```
with ResponseTimeout(node_timeout):
            resp = conn.getexpect()
```

If node_timeout's value is 3 and object-server respond after 2 seconds,
proxy-server wait 2 seconds.

Because proxy-server wait for the above response, the execution of the
following code is delayed.
(
https://github.com/openstack/swift/blob/stable/rocky/swift/proxy/controllers/obj.py#L627
)

```
for node in nodes:
            try:
                putter = self._make_putter(node, part, req, headers)
                self.app.set_node_timing(node, putter.connect_duration)
                return putter
```

This problem occurs when i do a ring rebalance.
When object-replicator delete a partition directory that are no longer
mine, the disk becomes very busy (Because of xfsaild daemon)
Because the disk are busy, object-server can't create diskfile during PUT
operation.

Is there anyone who is having problems like me?
How can I solve this problem?

I need everyone's help.
Thanks.

Best Regards
SeongSoo Cho

------
SeongSoo Cho (South Korea)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181029/dc319bb1/attachment.html>

From ppiyakk2 at printf.kr  Mon Oct 29 14:45:04 2018
From: ppiyakk2 at printf.kr (SeongSoo Cho)
Date: Mon, 29 Oct 2018 23:45:04 +0900
Subject: [Openstack] [Swift] PUT Object performance problem
In-Reply-To: <CAL2V8z72VbjUCaeStkQyxqMnvB_QmiSHAS5H8adBwiCbBT5oeg@mail.gmail.com>
References: <CAL2V8z72VbjUCaeStkQyxqMnvB_QmiSHAS5H8adBwiCbBT5oeg@mail.gmail.com>
Message-ID: <CAL2V8z6XTF8YpVrJdBpvLY733wiju=5Q-JFHg7hv4nxaN=GUFw@mail.gmail.com>

For more information, I use ocata version.

2018년 10월 29일 (월) 오후 10:07, SeongSoo Cho <ppiyakk2 at printf.kr>님이 작성:

> Hello, All
>
> I have a terrible problem with object server.
> Here is the case.
> 1. User upload an object to proxy-server
> 2. Proxy server try to connect with object-server
> 3. If one of object-server is slow to respond, proxy-server is waiting for
> response.
>   3.1 While waiting for response, proxy-server can't do anything
> 4. So, The response of client request will be delayed.
>
> In my opinion, this code seems to be a problem
> (
> https://github.com/openstack/swift/blob/stable/rocky/swift/proxy/controllers/obj.py#L1734
> )
>
> ```
> with ResponseTimeout(node_timeout):
>             resp = conn.getexpect()
> ```
>
> If node_timeout's value is 3 and object-server respond after 2 seconds,
> proxy-server wait 2 seconds.
>
> Because proxy-server wait for the above response, the execution of the
> following code is delayed.
> (
> https://github.com/openstack/swift/blob/stable/rocky/swift/proxy/controllers/obj.py#L627
> )
>
> ```
> for node in nodes:
>             try:
>                 putter = self._make_putter(node, part, req, headers)
>                 self.app.set_node_timing(node, putter.connect_duration)
>                 return putter
> ```
>
> This problem occurs when i do a ring rebalance.
> When object-replicator delete a partition directory that are no longer
> mine, the disk becomes very busy (Because of xfsaild daemon)
> Because the disk are busy, object-server can't create diskfile during PUT
> operation.
>
> Is there anyone who is having problems like me?
> How can I solve this problem?
>
> I need everyone's help.
> Thanks.
>
> Best Regards
> SeongSoo Cho
>
> ------
> SeongSoo Cho (South Korea)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181029/c199eedd/attachment.html>

From clay.gerrard at gmail.com  Mon Oct 29 16:42:17 2018
From: clay.gerrard at gmail.com (Clay Gerrard)
Date: Mon, 29 Oct 2018 11:42:17 -0500
Subject: [Openstack] [Swift] PUT Object performance problem
In-Reply-To: <CAL2V8z6XTF8YpVrJdBpvLY733wiju=5Q-JFHg7hv4nxaN=GUFw@mail.gmail.com>
References: <CAL2V8z72VbjUCaeStkQyxqMnvB_QmiSHAS5H8adBwiCbBT5oeg@mail.gmail.com>
 <CAL2V8z6XTF8YpVrJdBpvLY733wiju=5Q-JFHg7hv4nxaN=GUFw@mail.gmail.com>
Message-ID: <CA+_JKzq7_XHfFsSdqDXSk8PNRQt4uoWZOuUzFJMcA9OgSvC5kg@mail.gmail.com>

Obviously a re-balance will cost some IO, but it's normally perceptible to
the client unless you were already on a razor thin line.

Two config options seem obvious to think about experimenting with:

You could decrease the node_timeout and let the proxy try to write more to
handoffs
You could try to use some of the ionice options (or other tuning options)
to make the replicators hammer the disks a little less

It might having something to do with how you're organizing your ring weight
changes - could you describe how you're managing rings?
Could also be a io scheduling issue - are you using noop/deadline or cfq?
What kernel version?

-Clay


On Mon, Oct 29, 2018 at 9:55 AM SeongSoo Cho <ppiyakk2 at printf.kr> wrote:

> For more information, I use ocata version.
>
> 2018년 10월 29일 (월) 오후 10:07, SeongSoo Cho <ppiyakk2 at printf.kr>님이 작성:
>
>> Hello, All
>>
>> I have a terrible problem with object server.
>> Here is the case.
>> 1. User upload an object to proxy-server
>> 2. Proxy server try to connect with object-server
>> 3. If one of object-server is slow to respond, proxy-server is waiting
>> for response.
>>   3.1 While waiting for response, proxy-server can't do anything
>> 4. So, The response of client request will be delayed.
>>
>> In my opinion, this code seems to be a problem
>> (
>> https://github.com/openstack/swift/blob/stable/rocky/swift/proxy/controllers/obj.py#L1734
>> )
>>
>> ```
>> with ResponseTimeout(node_timeout):
>>             resp = conn.getexpect()
>> ```
>>
>> If node_timeout's value is 3 and object-server respond after 2 seconds,
>> proxy-server wait 2 seconds.
>>
>> Because proxy-server wait for the above response, the execution of the
>> following code is delayed.
>> (
>> https://github.com/openstack/swift/blob/stable/rocky/swift/proxy/controllers/obj.py#L627
>> )
>>
>> ```
>> for node in nodes:
>>             try:
>>                 putter = self._make_putter(node, part, req, headers)
>>                 self.app.set_node_timing(node, putter.connect_duration)
>>                 return putter
>> ```
>>
>> This problem occurs when i do a ring rebalance.
>> When object-replicator delete a partition directory that are no longer
>> mine, the disk becomes very busy (Because of xfsaild daemon)
>> Because the disk are busy, object-server can't create diskfile during PUT
>> operation.
>>
>> Is there anyone who is having problems like me?
>> How can I solve this problem?
>>
>> I need everyone's help.
>> Thanks.
>>
>> Best Regards
>> SeongSoo Cho
>>
>> ------
>> SeongSoo Cho (South Korea)
>>
>> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181029/8f4a7884/attachment.html>

From fungi at yuggoth.org  Mon Oct 29 16:53:47 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 29 Oct 2018 16:53:47 +0000
Subject: [Openstack] [all] We're combining the lists! (was: Bringing the
 community together...)
In-Reply-To: <20180920163248.oia5t7zjqcfwluwz@yuggoth.org>
References: <20180830170350.wrz4wlanb276kncb@yuggoth.org>
 <20180920163248.oia5t7zjqcfwluwz@yuggoth.org>
Message-ID: <20181029165346.vm6ptoqq5wkqban6@yuggoth.org>

REMINDER: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this is being sent) will
be replaced by a new openstack-discuss at lists.openstack.org mailing
list. The new list is open for subscriptions[0] now, but is not yet
accepting posts until Monday November 19 and it's strongly
recommended to subscribe before that date so as not to miss any
messages posted there. The old lists will be configured to no longer
accept posts starting on Monday December 3, but in the interim posts
to the old lists will also get copied to the new list so it's safe
to unsubscribe from them any time after the 19th and not miss any
messages. See my previous notice[1] for details.

For those wondering, we have 127 subscribers so far on
openstack-discuss with 3 weeks to go before it will be put into use
(and 5 weeks now before the old lists are closed down for good).

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181029/a8445ed1/attachment.sig>

From mrhillsman at gmail.com  Mon Oct 29 17:08:54 2018
From: mrhillsman at gmail.com (Melvin Hillsman)
Date: Mon, 29 Oct 2018 12:08:54 -0500
Subject: [Openstack] Fwd: [openstack-dev] [Openstack-sigs] [all][tc] We're
 combining the lists! (was: Bringing the community together...)
In-Reply-To: <CAOqvHK-ODpHw6nWdYxMoLRYPcn6Cg4PhuTEse8G_7HBEYznMEw@mail.gmail.com>
References: <20180830170350.wrz4wlanb276kncb@yuggoth.org>
 <20180920163248.oia5t7zjqcfwluwz@yuggoth.org>
 <1537479809-sup-898@lrrr.local>
 <CAOqvHK-ODpHw6nWdYxMoLRYPcn6Cg4PhuTEse8G_7HBEYznMEw@mail.gmail.com>
Message-ID: <CAMVtB2H28FqeFrDbMe64VCoknP+SOF=JFSxTv3=PE+DL1FbdMQ@mail.gmail.com>

---------- Forwarded message ---------
From: Samuel Cassiba <samuel at cassi.ba>
Date: Fri, Sep 21, 2018 at 12:15 AM
Subject: Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the
lists! (was: Bringing the community together...)
To: openstack-dev <openstack-dev at lists.openstack.org>


On Thu, Sep 20, 2018 at 2:48 PM Doug Hellmann <doug at doughellmann.com> wrote:
>
> Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +0000:
> > tl;dr: The openstack, openstack-dev, openstack-sigs and
> > openstack-operators mailing lists (to which this is being sent) will
> > be replaced by a new openstack-discuss at lists.openstack.org mailing
> > list.
>
> Since last week there was some discussion of including the openstack-tc
> mailing list among these lists to eliminate confusion caused by the fact
> that the list is not configured to accept messages from all subscribers
> (it's meant to be used for us to make sure TC members see meeting
> announcements).
>
> I'm inclined to include it and either use a direct mailing or the
> [tc] tag on the new discuss list to reach TC members, but I would
> like to hear feedback from TC members and other interested parties
> before calling that decision made. Please let me know what you think.
>
> Doug
>

+1 including the TC list as a tag makes sense to me and my tangent
about intent in online communities.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181029/4a219ed7/attachment.html>

From mrhillsman at gmail.com  Mon Oct 29 17:28:50 2018
From: mrhillsman at gmail.com (Melvin Hillsman)
Date: Mon, 29 Oct 2018 12:28:50 -0500
Subject: [Openstack] [user-committee] UC Meeting Reminder
Message-ID: <CAMVtB2HOWTr13GyKMUN7Nz_Fdb9Jq98dKgDFmt9n6AfaSdXxjg@mail.gmail.com>

UC meeting in #openstack-uc <irc://chat.freenode.net/#openstack-uc> at
1800UTC

-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181029/fbeaafb3/attachment.html>

From torin.woltjer at granddial.com  Mon Oct 29 20:50:39 2018
From: torin.woltjer at granddial.com (Torin Woltjer)
Date: Mon, 29 Oct 2018 20:50:39 GMT
Subject: [Openstack] DHCP not accessible on new compute node.
Message-ID: <b48d42c8f51f4363b9582f1405983568@granddial.com>

Recently installed a new compute node, but noticed none of the instances that I put on it will successfully receive network addresses from DHCP. This seems to work on all other compute nodes however. When listening for DHCP requests on the vxlan of the compute node, I notice that while I can see the DHCP requests on the new compute node, I do not see them anywhere else. If I manually assign an address to the interface on the instance I am able to ping in and out. Running dhclient -v on an instance on a working compute node successfully gets a DHCP response, on the new compute node there is no response, I also discovered that the instance on the new compute node cannot ping the DHCP ports at 172.16.1.2 & 172.16.1.3 yet can ping the gateway at 172.16.1.1.

The setup is neutron-linuxbridge on Openstack Queens.

Torin Woltjer
 
Grand Dial Communications - A ZK Tech Inc. Company
 
616.776.1066 ext. 2006
www.granddial.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181029/4f091594/attachment-0001.html>

From marcioprado at marcioprado.eti.br  Mon Oct 29 21:08:41 2018
From: marcioprado at marcioprado.eti.br (Marcio Prado)
Date: Mon, 29 Oct 2018 18:08:41 -0300
Subject: [Openstack] DHCP not accessible on new compute node.
In-Reply-To: <b48d42c8f51f4363b9582f1405983568@granddial.com>
Message-ID: <305a867d-3e98-487c-acca-06bdb1e123e3@email.android.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181029/c84667c3/attachment.html>

From naftinajeh94 at gmail.com  Mon Oct 29 21:53:24 2018
From: naftinajeh94 at gmail.com (Najeh Nafti)
Date: Mon, 29 Oct 2018 22:53:24 +0100
Subject: [Openstack] setup private cloud environment
Message-ID: <CAGJVRxq_+a0LKziQHshfbjAryiU2=jRi90BXWb3bFayMKHefcw@mail.gmail.com>

Dear Sir/Madam,

I want to setup my own private cloud using 3 desktop machines with
openstack.

Could you please give me the steps to build this cloud ?
How can i configure and connect the machines together to build my own
private cloud?
Regards.
Najeh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181029/da4ba869/attachment.html>

From jburckhardt at pdvwireless.com  Mon Oct 29 23:03:55 2018
From: jburckhardt at pdvwireless.com (Jacob Burckhardt)
Date: Mon, 29 Oct 2018 23:03:55 +0000
Subject: [Openstack] my ask.openstack.org question has waited for moderator
 approval for 17 days
Message-ID: <CY4PR22MB023021C6CCEEF83CE35A5B3ABBF30@CY4PR22MB0230.namprd22.prod.outlook.com>

My question on ask.openstack.org says "This post is awaiting moderation".  

It has been like that for 17 days.  If you are a moderator, I'd appreciate if you'd decide whether to publicly post my question:

https://ask.openstack.org/en/question/116591/is-there-example-of-using-python-zunclient-api/

Thanks.

-Jacob Burckhardt


From berndbausch at gmail.com  Mon Oct 29 23:16:05 2018
From: berndbausch at gmail.com (Bernd Bausch)
Date: Tue, 30 Oct 2018 08:16:05 +0900
Subject: [Openstack] my ask.openstack.org question has waited for
 moderator approval for 17 days
In-Reply-To: <CY4PR22MB023021C6CCEEF83CE35A5B3ABBF30@CY4PR22MB0230.namprd22.prod.outlook.com>
References: <CY4PR22MB023021C6CCEEF83CE35A5B3ABBF30@CY4PR22MB0230.namprd22.prod.outlook.com>
Message-ID: <b7e142c8-f672-d4fb-0266-21cb2d323e38@gmail.com>

If there is a shortage of moderators, I volunteer.

On 10/30/2018 8:03 AM, Jacob Burckhardt wrote:
> My question on ask.openstack.org says "This post is awaiting moderation".  
>
> It has been like that for 17 days.  If you are a moderator, I'd appreciate if you'd decide whether to publicly post my question:
>
> https://ask.openstack.org/en/question/116591/is-there-example-of-using-python-zunclient-api/
>
> Thanks.
>
> -Jacob Burckhardt
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181030/d7d05255/attachment.sig>

From berndbausch at gmail.com  Mon Oct 29 23:28:40 2018
From: berndbausch at gmail.com (Bernd Bausch)
Date: Tue, 30 Oct 2018 08:28:40 +0900
Subject: [Openstack] setup private cloud environment
In-Reply-To: <CAGJVRxq_+a0LKziQHshfbjAryiU2=jRi90BXWb3bFayMKHefcw@mail.gmail.com>
References: <CAGJVRxq_+a0LKziQHshfbjAryiU2=jRi90BXWb3bFayMKHefcw@mail.gmail.com>
Message-ID: <99faecdc-a669-6d5d-e4d4-c9e280c51d5b@gmail.com>

Recommendation: Use the installation tutorials on docs.openstack.org.
They start with a two-node cloud, but depending on how you want to use
your three boxes, it should be no problem extending the setup to three.
This will be a very manual setup, time-consuming but with a great
learning effect.

There are several automatic or semi-automatic deployment tools that you
should evaluate: Packstack (very easy), Kolla and Kolla-Ansible,
OpenStack-Ansible. The latter two may require more power than a typical
PC delivers. Their advantage: They can set up highly available clouds.

Devstack is another solution. I don't know how hard it is to extend a
single-node setup to three nodes. Since Devstack's purpose is
development and testing, it doesn't really focus on robustness.

Triple-O is probably not for you, as it requires servers with IPMI
interface. But there are ways to virtualize IPMI, so that you should
evaluate this method as well.

I am sure there are other methods. One thing to consider: Setting up an
OpenStack cloud is not like installing a typical Linux box. There are
many (many!) moving parts and many (many!) opportunities to make
mistakes. Keep that in mind and don't give up.

Bernd Bausch

On 10/30/2018 6:53 AM, Najeh Nafti wrote:
> Dear Sir/Madam,
>
> I want to setup my own private cloud using 3 desktop machines with
> openstack.
>
> Could you please give me the steps to build this cloud ?
> How can i configure and connect the machines together to build my own
> private cloud?
> Regards.
> Najeh.
>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181030/68541b1a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181030/68541b1a/attachment.sig>

From ppiyakk2 at printf.kr  Tue Oct 30 01:45:04 2018
From: ppiyakk2 at printf.kr (SeongSoo Cho)
Date: Tue, 30 Oct 2018 10:45:04 +0900
Subject: [Openstack] [Swift] PUT Object performance problem
In-Reply-To: <CA+_JKzq7_XHfFsSdqDXSk8PNRQt4uoWZOuUzFJMcA9OgSvC5kg@mail.gmail.com>
References: <CAL2V8z72VbjUCaeStkQyxqMnvB_QmiSHAS5H8adBwiCbBT5oeg@mail.gmail.com>
 <CAL2V8z6XTF8YpVrJdBpvLY733wiju=5Q-JFHg7hv4nxaN=GUFw@mail.gmail.com>
 <CA+_JKzq7_XHfFsSdqDXSk8PNRQt4uoWZOuUzFJMcA9OgSvC5kg@mail.gmail.com>
Message-ID: <CAL2V8z57Tqu1Kbtei_eLoPyGiA+xb=doMeN5uGY3=ovXiryxig@mail.gmail.com>

Hi clay

I just using the command like `swift-ring-builder object.builder
set_weight  d234 2220`.
Then execute `swift-ring-builder object.builder rebalance` and push the
rings all object node.

Here is more detail information.
I/O scheduler : deadline
OS : CentOS 7.4
Kernel version : 3.10.0-693.11.1.el7.x86_64

I will try decrease the node_timeout from 3 to 1.  (Do you have any
recommend value?)

On Tue, Oct 30, 2018 at 1:42 AM Clay Gerrard <clay.gerrard at gmail.com> wrote:

> Obviously a re-balance will cost some IO, but it's normally perceptible to
> the client unless you were already on a razor thin line.
>
> Two config options seem obvious to think about experimenting with:
>
> You could decrease the node_timeout and let the proxy try to write more to
> handoffs
> You could try to use some of the ionice options (or other tuning options)
> to make the replicators hammer the disks a little less
>
> It might having something to do with how you're organizing your ring
> weight changes - could you describe how you're managing rings?
> Could also be a io scheduling issue - are you using noop/deadline or cfq?
> What kernel version?
>
> -Clay
>
>
> On Mon, Oct 29, 2018 at 9:55 AM SeongSoo Cho <ppiyakk2 at printf.kr> wrote:
>
>> For more information, I use ocata version.
>>
>> 2018년 10월 29일 (월) 오후 10:07, SeongSoo Cho <ppiyakk2 at printf.kr>님이 작성:
>>
>>> Hello, All
>>>
>>> I have a terrible problem with object server.
>>> Here is the case.
>>> 1. User upload an object to proxy-server
>>> 2. Proxy server try to connect with object-server
>>> 3. If one of object-server is slow to respond, proxy-server is waiting
>>> for response.
>>>   3.1 While waiting for response, proxy-server can't do anything
>>> 4. So, The response of client request will be delayed.
>>>
>>> In my opinion, this code seems to be a problem
>>> (
>>> https://github.com/openstack/swift/blob/stable/rocky/swift/proxy/controllers/obj.py#L1734
>>> )
>>>
>>> ```
>>> with ResponseTimeout(node_timeout):
>>>             resp = conn.getexpect()
>>> ```
>>>
>>> If node_timeout's value is 3 and object-server respond after 2 seconds,
>>> proxy-server wait 2 seconds.
>>>
>>> Because proxy-server wait for the above response, the execution of the
>>> following code is delayed.
>>> (
>>> https://github.com/openstack/swift/blob/stable/rocky/swift/proxy/controllers/obj.py#L627
>>> )
>>>
>>> ```
>>> for node in nodes:
>>>             try:
>>>                 putter = self._make_putter(node, part, req, headers)
>>>                 self.app.set_node_timing(node, putter.connect_duration)
>>>                 return putter
>>> ```
>>>
>>> This problem occurs when i do a ring rebalance.
>>> When object-replicator delete a partition directory that are no longer
>>> mine, the disk becomes very busy (Because of xfsaild daemon)
>>> Because the disk are busy, object-server can't create diskfile during
>>> PUT operation.
>>>
>>> Is there anyone who is having problems like me?
>>> How can I solve this problem?
>>>
>>> I need everyone's help.
>>> Thanks.
>>>
>>> Best Regards
>>> SeongSoo Cho
>>>
>>> ------
>>> SeongSoo Cho (South Korea)
>>>
>>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181030/ceb8c089/attachment.html>

From tony at bakeyournoodle.com  Tue Oct 30 05:40:25 2018
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Tue, 30 Oct 2018 16:40:25 +1100
Subject: [Openstack] [all]Naming the T release of OpenStack -- Poll open
Message-ID: <20181030054024.GC2343@thor.bakeyournoodle.com>

Hi folks,

It is time again to cast your vote for the naming of the T Release.
As with last time we'll use a public polling option over per user private URLs
for voting.  This means, everybody should proceed to use the following URL to
cast their vote:

  https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_aac97f1cbb6c61df&akey=b9e448b340787f0e

We've selected a public poll to ensure that the whole community, not just gerrit
change owners get a vote.  Also the size of our community has grown such that we
can overwhelm CIVS if using private urls.  A public can mean that users
behind NAT, proxy servers or firewalls may receive an message saying
that your vote has already been lodged, if this happens please try
another IP.

Because this is a public poll, results will currently be only viewable by myself
until the poll closes. Once closed, I'll post the URL making the results
viewable to everybody. This was done to avoid everybody seeing the results while
the public poll is running.

The poll will officially end on 2018-11-08 00:00:00+00:00[1], and results will be
posted shortly after.

[1] https://governance.openstack.org/tc/reference/release-naming.html
---

According to the Release Naming Process, this poll is to determine the
community preferences for the name of the T release of OpenStack. It is
possible that the top choice is not viable for legal reasons, so the second or
later community preference could wind up being the name.

Release Name Criteria
---------------------

Each release name must start with the letter of the ISO basic Latin alphabet
following the initial letter of the previous release, starting with the
initial release of "Austin". After "Z", the next name should start with
"A" again.

The name must be composed only of the 26 characters of the ISO basic Latin
alphabet. Names which can be transliterated into this character set are also
acceptable.

The name must refer to the physical or human geography of the region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic region under
consideration must be declared before the opening of nominations, as part of
the initiation of the selection process.

The name must be a single word with a maximum of 10 characters. Words that
describe the feature should not be included, so "Foo City" or "Foo Peak"
would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may make
an exception for one or more of them to be considered in the Condorcet poll.
The naming official is responsible for presenting the list of exceptional
names for consideration to the TC before the poll opens.

Exact Geographic Region
-----------------------

The Geographic Region from where names for the S release will come is Colorado

Proposed Names
--------------

* Tarryall
* Teakettle
* Teller
* Telluride
* Thomas : the Tank Engine
* Thornton
* Tiger
* Tincup
* Timnath
* Timber
* Tiny Town
* Torreys
* Trail
* Trinidad
* Treasure
* Troublesome
* Trussville
* Turret
* Tyrone

Proposed Names that do not meet the criteria (accepted by the TC)
-----------------------------------------------------------------

* Train🚂 : Many Attendees of the first Denver PTG have a story to tell about the trains near the PTG hotel.  We could celebrate those stories with this name

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181030/02275154/attachment.sig>

From dev.faz at gmail.com  Tue Oct 30 11:37:50 2018
From: dev.faz at gmail.com (Fabian Zimmermann)
Date: Tue, 30 Oct 2018 12:37:50 +0100
Subject: [Openstack] missing ovs flows and extra interfaces in pike
In-Reply-To: <20181026141545.v63fvxrfjmtbibyu@alle-irre.de>
References: <20181019133242.xbmibiqh6wwiwuzm@alle-irre.de>
 <eec163a5-ecfc-8c18-1155-a07a2e84f926@gmail.com>
 <20181026141545.v63fvxrfjmtbibyu@alle-irre.de>
Message-ID: <d4f3adde-155b-3973-916e-7d992dfd30e0@gmail.com>

Hi,

you may contact me directly, this would speed up my responsetime ;)

Am 26.10.18 um 16:15 schrieb Hartwig Hauschild:
> We thought we're missing the flow for "if you're looking for this MAC go
> this way", but it turned out that what's actually missing is a bunch of
> interfaces on the multicast-flow for the vlan that we're investigating.
> 
> Is that what you're seeing as well?

exactly.

I wrote a small script which uses the database to calculate which 
network is located on which HV and checks if there are suitable 
vxlan-tunnel build.

Its a quick and dirty hack, but works for us (so far).

I personally dont like publishing code in this quality, but I dont think 
I will improve this in the near future - so here maybe it helps you a bit.

https://github.com/noris-network/check_vxlan_mesh

If you have any questions, dont hesitate to ask.

  Fabian


From torin.woltjer at granddial.com  Tue Oct 30 14:37:43 2018
From: torin.woltjer at granddial.com (Torin Woltjer)
Date: Tue, 30 Oct 2018 14:37:43 GMT
Subject: [Openstack] DHCP not accessible on new compute node.
Message-ID: <eca77537af444a0fb34c9d1ef9a380ef@granddial.com>

I deleted both DHCP ports and they recreated as you said. However, instances are still unable to get network addresses automatically.

Torin Woltjer
 
Grand Dial Communications - A ZK Tech Inc. Company
 
616.776.1066 ext. 2006
www.granddial.com

----------------------------------------
From: Marcio Prado <marcioprado at marcioprado.eti.br>
Sent: 10/29/18 6:23 PM
To: torin.woltjer at granddial.com
Subject: Re: [Openstack] DHCP not accessible on new compute node.
The door is recreated automatically. The problem like I said is not in
DHCP, but for some reason, erasing and waiting for OpenStack to
re-create the port often solves the problem.

Please, if you can find out the problem in fact, let me know. I'm very
interested to know.

You can delete the door without fear. OpenStack will recreate in a short
time.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181030/a70bc6df/attachment.html>

From jimmy at openstack.org  Tue Oct 30 16:00:24 2018
From: jimmy at openstack.org (Jimmy McArthur)
Date: Tue, 30 Oct 2018 11:00:24 -0500
Subject: [Openstack] my ask.openstack.org question has waited for
 moderator approval for 17 days
In-Reply-To: <b7e142c8-f672-d4fb-0266-21cb2d323e38@gmail.com>
References: <CY4PR22MB023021C6CCEEF83CE35A5B3ABBF30@CY4PR22MB0230.namprd22.prod.outlook.com>
 <b7e142c8-f672-d4fb-0266-21cb2d323e38@gmail.com>
Message-ID: <5BD88018.6010707@openstack.org>

Hey Bernd - Thank you for the offer!  I just updated your account to 
Moderator status.  You may need to log out, then back in.

> Bernd Bausch <mailto:berndbausch at gmail.com>
> October 29, 2018 at 6:16 PM
> If there is a shortage of moderators, I volunteer.
>
>
> _______________________________________________
> Mailing list: 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack at lists.openstack.org
> Unsubscribe : 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Jacob Burckhardt <mailto:jburckhardt at pdvwireless.com>
> October 29, 2018 at 6:03 PM
> My question on ask.openstack.org says "This post is awaiting moderation".
>
> It has been like that for 17 days. If you are a moderator, I'd 
> appreciate if you'd decide whether to publicly post my question:
>
> https://ask.openstack.org/en/question/116591/is-there-example-of-using-python-zunclient-api/
>
> Thanks.
>
> -Jacob Burckhardt
>
> _______________________________________________
> Mailing list: 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack at lists.openstack.org
> Unsubscribe : 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181030/7138a593/attachment.html>

From jimmy at openstack.org  Tue Oct 30 16:01:31 2018
From: jimmy at openstack.org (Jimmy McArthur)
Date: Tue, 30 Oct 2018 11:01:31 -0500
Subject: [Openstack] my ask.openstack.org question has waited for
 moderator approval for 17 days
In-Reply-To: <CY4PR22MB023021C6CCEEF83CE35A5B3ABBF30@CY4PR22MB0230.namprd22.prod.outlook.com>
References: <CY4PR22MB023021C6CCEEF83CE35A5B3ABBF30@CY4PR22MB0230.namprd22.prod.outlook.com>
Message-ID: <5BD8805B.7050009@openstack.org>

Jacob,

Thanks for the heads up.  We've just added another moderator and I've 
cleared out the back log.  Apologies for the oversight.  We'll keep an 
eye on this more closely moving forward.

Best,
Jimmy

> Jacob Burckhardt <mailto:jburckhardt at pdvwireless.com>
> October 29, 2018 at 6:03 PM
> My question on ask.openstack.org says "This post is awaiting moderation".
>
> It has been like that for 17 days. If you are a moderator, I'd 
> appreciate if you'd decide whether to publicly post my question:
>
> https://ask.openstack.org/en/question/116591/is-there-example-of-using-python-zunclient-api/
>
> Thanks.
>
> -Jacob Burckhardt
>
> _______________________________________________
> Mailing list: 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack at lists.openstack.org
> Unsubscribe : 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181030/aa86bf24/attachment.html>

From torin.woltjer at granddial.com  Tue Oct 30 20:50:58 2018
From: torin.woltjer at granddial.com (Torin Woltjer)
Date: Tue, 30 Oct 2018 20:50:58 GMT
Subject: [Openstack] DHCP not accessible on new compute node.
Message-ID: <a042e38a04344348af2f54ac95662c42@granddial.com>

Interestingly, I created a brand new selfservice network and DHCP doesn't work on that either. I've followed the instructions in the minimal setup (excluding the controllers as they're already set up) but the new node has no access to the DHCP agent in neutron it seems. Is there a likely component that I've overlooked?

Torin Woltjer
 
Grand Dial Communications - A ZK Tech Inc. Company
 
616.776.1066 ext. 2006
www.granddial.com

----------------------------------------
From: "Torin Woltjer" <torin.woltjer at granddial.com>
Sent: 10/30/18 10:48 AM
To: <marcioprado at marcioprado.eti.br>, "openstack at lists.openstack.org" <openstack at lists.openstack.org>
Subject: Re: [Openstack] DHCP not accessible on new compute node.
I deleted both DHCP ports and they recreated as you said. However, instances are still unable to get network addresses automatically.

Torin Woltjer
 
Grand Dial Communications - A ZK Tech Inc. Company
 
616.776.1066 ext. 2006
www.granddial.com

----------------------------------------
From: Marcio Prado <marcioprado at marcioprado.eti.br>
Sent: 10/29/18 6:23 PM
To: torin.woltjer at granddial.com
Subject: Re: [Openstack] DHCP not accessible on new compute node.
The door is recreated automatically. The problem like I said is not in
DHCP, but for some reason, erasing and waiting for OpenStack to
re-create the port often solves the problem.

Please, if you can find out the problem in fact, let me know. I'm very
interested to know.

You can delete the door without fear. OpenStack will recreate in a short
time.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181030/2f3fec22/attachment.html>

From tony at bakeyournoodle.com  Wed Oct 31 01:01:31 2018
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Wed, 31 Oct 2018 12:01:31 +1100
Subject: [Openstack] [openstack-dev] [all]Naming the T release of
 OpenStack -- Poll open
In-Reply-To: <CACDL7B2-=darGhtqYnCmhnUc_+z+LK9+R0VPs9z2YxKH+8dkiw@mail.gmail.com>
References: <20181030054024.GC2343@thor.bakeyournoodle.com>
 <CACDL7B2-=darGhtqYnCmhnUc_+z+LK9+R0VPs9z2YxKH+8dkiw@mail.gmail.com>
Message-ID: <20181031010130.GE2343@thor.bakeyournoodle.com>

On Tue, Oct 30, 2018 at 11:25:02AM -0700, iain macdonnell wrote:
> I must be losing it. On what planet is "Tiny Town" a single word, and
> "Troublesome" not more than 10 characters?

Sorry for the mistake.  Should either of these names win the popular
vote clearly they would not be viable.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181031/22db85bd/attachment.sig>