Re: [openstack-dev] [congress] ocata client causes feature regression with pre-ocata server

[Eric K]

Hi Tim,
I thought something like that would work. But actually python-congressclient
is not a listed requirement of congress server, no vice versa. Which is
correct in the sense that installing and running one does not require
installing the other on the same machine.

From:  Tim Hinrichs 
Date:  Saturday, January 21, 2017 at 2:33 PM
To:  Eric Kao , "OpenStack Development Mailing
List (not for usage questions)" 
Subject:  Re: [congress] ocata client causes feature regression with
pre-ocata server

> How about we go into the preocata server and change requirements.txt to ensure
> it only supports the older clients. Something like...
> 
> Python-congressclient>2.3<2.5
> 
> Or whatever the versions are.
> 
> Tim
> 
> 
> On Fri, Jan 20, 2017 at 7:07 PM Eric K  wrote:
>> Hi all,
>> 
>> I was getting ready to request release of congress client, but I
>> remembered that the new client causes feature regression if used with
>> older versions of congress. Specifically, new client with pre-Ocata
>> congress cannot refer to datasource by name, something that could be done
>> with pre-Ocata client.
>> 
>> Here¹s the patch of interest: https://review.openstack.org/#/c/407329/
>> 
>> 
>> A few questions:
>> 
>> Are we okay with the regression? Seems like it could cause a fair bit of
>> annoyance for users.
>>1. If we¹re okay with that, what¹s the best way to document that
>> pre-Ocata congress should be used with pre-Ocata client?
>>2. If not, how we avoid the regression? Here are some candidates I can
>> think of.
>>   a. Client detects congress version and act accordingly. I don¹t
>> think this is possible, nor desirable for client to be concerned with
>> congress version not just API version.
>>   b. Release backward compatible API version 1.1 that supports
>> getting datasource by name_or_id. Then client will take different paths
>> depending on API version.
>>   c. If datasource not found, client falls back on old method of
>> retrieving list of datasources to resolve name into UUID. This would work,
>> but causes extra API & DB call in many cases.
>>   d. Patch old versions of Congress to support getting datasource
>> by name_or_id. Essentially, it was always a bug that the API didn¹t
>> support name_or_id.
>> 
>> Thanks!
>> 
>> 


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

Re: [openstack-dev] [congress] ocata client causes feature regression with pre-ocata server

[Tim Hinrichs]

How about we go into the preocata server and change requirements.txt to
ensure it only supports the older clients. Something like...

Python-congressclient>2.3<2.5

Or whatever the versions are.

Tim


On Fri, Jan 20, 2017 at 7:07 PM Eric K  wrote:

> Hi all,
>
> I was getting ready to request release of congress client, but I
> remembered that the new client causes feature regression if used with
> older versions of congress. Specifically, new client with pre-Ocata
> congress cannot refer to datasource by name, something that could be done
> with pre-Ocata client.
>
> Here¹s the patch of interest: https://review.openstack.org/#/c/407329/
> 
>
> A few questions:
>
> Are we okay with the regression? Seems like it could cause a fair bit of
> annoyance for users.
>1. If we¹re okay with that, what¹s the best way to document that
> pre-Ocata congress should be used with pre-Ocata client?
>2. If not, how we avoid the regression? Here are some candidates I can
> think of.
>   a. Client detects congress version and act accordingly. I don¹t
> think this is possible, nor desirable for client to be concerned with
> congress version not just API version.
>   b. Release backward compatible API version 1.1 that supports
> getting datasource by name_or_id. Then client will take different paths
> depending on API version.
>   c. If datasource not found, client falls back on old method of
> retrieving list of datasources to resolve name into UUID. This would work,
> but causes extra API & DB call in many cases.
>   d. Patch old versions of Congress to support getting datasource
> by name_or_id. Essentially, it was always a bug that the API didn¹t
> support name_or_id.
>
> Thanks!
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [vote][kolla] deprecation for Debian distro support

[Michał Jastrzębski]

2 as well, on multiple occasions we asked for maintainers to
volunteer, however there have been little response.

On 21 January 2017 at 05:51, Jeffrey Zhang  wrote:
> 2
>
> On Thu, Jan 19, 2017 at 7:53 PM, Mauricio Lima 
> wrote:
>>
>> 2
>>
>> 2017-01-19 8:50 GMT-03:00 Steven Dake (stdake) :
>>>
>>> My vote is for option 2 to deprecate Debian as there has been very little
>>> activity and operators seem uninterested in Debian as a platform.
>>>
>>> We could always add it back in at a later date if operators were to
>>> request it and the Debian team were interested in maintaining it.
>>>
>>> Regards
>>> -steve
>>>
>>>
>>> -Original Message-
>>> From: Christian Berendt 
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Date: Thursday, January 19, 2017 at 3:53 AM
>>> To: "openstack-dev@lists.openstack.org"
>>> 
>>> Subject: [openstack-dev] [vote][kolla] deprecation for Debian distro
>>> support
>>>
>>> As discussed in one of the last team meetings I want to propose the
>>> deprecation (this cycle) and removal (next cycle) of the Debian support in
>>> Kolla.
>>>
>>> More than 1 week ago I sent a pre warning mail to the
>>> openstack-operators mailing list, without any reply [0].
>>>
>>> Kolla core reviewers, please vote now. The vote will be open for 7
>>> days (26.01.2017).
>>>
>>> 1. Kolla needs support for Debian, it should not be deprecated
>>>
>>> 2. Kolla should deprecate support for Debian
>>>
>>> [0]
>>> http://lists.openstack.org/pipermail/openstack-operators/2017-January/012427.html
>>>
>>> --
>>> Christian Berendt
>>> Chief Executive Officer (CEO)
>>>
>>> Mail: bere...@betacloud-solutions.de
>>> Web: https://www.betacloud-solutions.de
>>>
>>> Betacloud Solutions GmbH
>>> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>>>
>>> Geschäftsführer: Christian Berendt
>>> Unternehmenssitz: Stuttgart
>>> Amtsgericht: Stuttgart, HRB 756139
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [ovs-discuss] [Neutron][networking-ovn] OVN + Openstack Issues

[Martin Mailand]

Hi Numan,

the security groups were the issue, I deleted them in Openstack, resynced and 
recreated them.

Thanks for your help.

best regards,
 martin

> Am 21.01.2017 um 18:17 schrieb Numan Siddique :
> 
> ​Looks like the Northbound db is not in sync with neutron db.
> Can you run the command "ovn-nbctl list Address_Set" and see if there is a 
> row for the each of the security groups ?
> 
> If you see the ovn northbound db is not in sync, you can sync it by either 
> running the neutron-ovn-db-sync util or by restarting the neutron-server 
> after setting ovn-sync-mode=repair in /etc/neutron/plugins/ml2/ml2_conf.ini


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

Re: [openstack-dev] [ovs-discuss] [Neutron][networking-ovn] OVN + Openstack Issues

[Numan Siddique]

Adding openstack-dev mailing list as it is more relevant.

Please see inline for some comments.
​​

On Sat, Jan 21, 2017 at 9:12 PM, Martin Mailand  wrote:

> Hi,
>
> I tried to use OVN with Openstack, but I ran into an Issue.
>
> I use the OVN packages from the Canonical Cloud archive:
>
> On the controller node:
> ii  ovn-central  2.6.0-0ubuntu2~cloud0
>amd64OVN central components
> ii  ovn-common   2.6.0-0ubuntu2~cloud0
>amd64OVN common components
> ii  ovn-host 2.6.0-0ubuntu2~cloud0
>amd64OVN host components
> ii  python-networking-ovn1.0.1.dev4.201610261100.xenial-0ubuntu1
> all  OpenStack virtual network service - OVN driver
>
> On the compute node:
>
> ii  ovn-common   2.6.0-0ubuntu2~cloud0
>   amd64OVN common components
> ii  ovn-host 2.6.0-0ubuntu2~cloud0
>   amd64OVN host components
>
> If I create a network in Openstack I can see it in the norhd.
>
> ovn-nbctl show
> switch 5cd02e8c-aa16-4246-932e-c1455958daa6
> (neutron-83a25bd6-494b-4d9d-ba74-e824a8efb826)
>
> And I can see my compute nodes
>
> ovn-sbctl show
> Chassis "4a191104-a3b6-4bde-82ee-1a09ea1b9f17"
> hostname: "compute03"
> Encap vxlan
> ip: "172.16.44.130"
> options: {csum="true"}
> Encap geneve
> ip: "172.16.44.130"
> options: {csum="true"}
> Chassis "b0623e67-a2cf-4802-9343-807383e3eb94"
> hostname: "compute01"
> Encap geneve
> ip: "172.16.44.17"
> options: {csum="true"}
> Encap vxlan
> ip: "172.16.44.17"
> options: {csum="true“}
>
>
> But if I try to start a VM I get an error in the neutron-server log, could
> you please advise me
> where my mistake is?
>
> Best regards,
> martin
>
> log:
>
> 2017-01-21 15:33:42.239 10877 ERROR neutron.agent.ovsdb.impl_idl
> [req-fee0a2c8-b205-4e1e-8756-026880fe84cd 44ea98f941ce412d999b3c3dd7fe1dad
> afc5c0f383314e74bdd6bf1e3afbf509 - - -] Traceback (most recent call last):
>   File 
> "/usr/lib/python2.7/dist-packages/neutron/agent/ovsdb/native/connection.py",
> line 115, in run
> txn.results.put(txn.do_commit())
>   File "/usr/lib/python2.7/dist-packages/neutron/agent/ovsdb/impl_idl.py",
> line 105, in do_commit
> ctx.reraise = False
>   File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line
> 220, in __exit__
> self.force_reraise()
>   File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line
> 196, in force_reraise
> six.reraise(self.type_, self.value, self.tb)
>   File "/usr/lib/python2.7/dist-packages/neutron/agent/ovsdb/impl_idl.py",
> line 100, in do_commit
> command.run_idl(txn)
>   File "/usr/lib/python2.7/dist-packages/networking_ovn/ovsdb/commands.py",
> line 712, in run_idl
> raise RuntimeError(msg)
> RuntimeError: Address set as_ip4_c67f0b5b_ce6f_4a82_aa48_803f00b15300
> does not exist. Can't update addresses
>
>
​Looks like the Northbound db is not in sync with neutron db.
Can you run the command "ovn-nbctl list Address_Set" and see if there is a
row for the each of the security groups ?

If you see the ovn northbound db is not in sync, you can sync it by either
running the neutron-ovn-db-sync util or by restarting the neutron-server
after setting ovn-sync-mode=repair in /etc/neutron/plugins/ml2/ml2_conf.ini

Do you see the same issue with devstack ?

Thanks
Numan


​


> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers
> [req-fee0a2c8-b205-4e1e-8756-026880fe84cd 44ea98f941ce412d999b3c3dd7fe1dad
> afc5c0f383314e74bdd6bf1e3afbf509 - - -] Mechanism driver 'ovn' failed in
> create_port_postcommit
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers Traceback
> (most recent call last):
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers   File
> "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py", line
> 433, in _call_on_drivers
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers
>  getattr(driver.obj, method_name)(context)
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers   File
> "/usr/lib/python2.7/dist-packages/networking_ovn/ml2/mech_driver.py",
> line 556, in create_port_postcommit
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers
>  self.create_port_in_ovn(port, ovn_port_info)
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers   File
> "/usr/lib/python2.7/dist-packages/networking_ovn/ml2/mech_driver.py",
> line 657, in create_port_in_ovn
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers
>  if_exists=False))
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers   File
> "/usr/lib/python2.7/dist-packages/neutron/agent/ovsdb/api.py", line 76,
> in __exit__
> 2017-01-21 15:33:42.240 10877 ERROR neutron.plugins.ml2.managers
>  self.result = self.commit()
> 

Re: [openstack-dev] [tripleo] Atlanta PTG

[Emilien Macchi]

On Sat, Jan 21, 2017 at 5:37 AM, Michele Baldessari  wrote:
> Hi Emilien,
>
> while not a design session per se, I would love to propose a short slot
> for TripleO CI Q, if we have some time left. In short, I'd like to be
> more useful around CI failures, but I lack the understanding of a few
> aspects of our current CI (promotion, when do images get built, etc.),
> that would benefit quite a bit from a short session where we have a few
> CI folks in the room that could answer questions or give some tips.
> I know of quite few other people that are in the same boat and maybe
> this will help a bit our current issue where only a few folks always
> chase CI issues.
>
> If there is consensus (and some CI folks willing to attend ;) and time
> for this, I'll be happy to organize this and prepare a bunch of
> questions ideas beforehand.

That would be *awesome* and yes we'll take time to do it, and even
record it if possible.

Thank you!

> Thoughts?
> Michele
>
> On Wed, Jan 04, 2017 at 07:26:52AM -0500, Emilien Macchi wrote:
>> I would like to bring this topic up on your inbox, so we can continue
>> to make progress on the agenda. Feel free to follow existing examples
>> in the etherpad and propose a design dession.
>>
>> Thanks,
>>
>> On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi  wrote:
>> > General infos about PTG: https://www.openstack.org/ptg/
>> >
>> > Some useful informations about PTG/TripleO:
>> >
>> > * When? We have a room between Wednesday and Friday included.
>> > Important sessions will happen on Wednesday and Thursday. We'll
>> > probably have sessions on Friday, but it might be more hands-on and
>> > hackfest, where people can enjoy the day to work together.
>> >
>> > * Let's start to brainstorm our topics:
>> > https://etherpad.openstack.org/p/tripleo-ptg-pike
>> >   Feel free to add any topic, as soon as you can. We need to know asap
>> > which sessions will be share with other projects (eg: tripleo/mistral,
>> > tripleo/ironic, tripleo/heat, etc).
>> >
>> >
>> > Please let us know any question or feedback,
>> > Looking forward to seeing you there!
>> > --
>> > Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Michele Baldessari
> C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D



-- 
Emilien Macchi

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

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

[Hayes, Graham]

On 20/01/17 01:40, Mike Perez wrote:
> On 17:38 Jan 18, Morales, Victor wrote:
>> Just a FYI, Ankur have been working on have a Feature Classification Matrix
>> in Neutron[1] which collects some of this information
>>
>> [1] https://review.openstack.org/#/c/318192/
> 
> I actually didn't know Nova also generated this with a script and ini file.
> Perhaps this would be a better approach than a giant JSON file like driver log
> is today. I could then have the marketplace parse these ini files using the
> common script. What do others think?
> 

FWIW Designate also does this - [0] is generated by [1] and a modified
version of the Nova script.

If there is a common way, we will use that, but I like our current
implementation.

0 - http://docs.openstack.org/developer/designate/support-matrix.html
1 -
https://git.openstack.org/cgit/openstack/designate/tree/doc/source/support-matrix.ini


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

Re: [openstack-dev] [vote][kolla] deprecation for Debian distro support

[Jeffrey Zhang]

2

On Thu, Jan 19, 2017 at 7:53 PM, Mauricio Lima 
wrote:

> 2
>
> 2017-01-19 8:50 GMT-03:00 Steven Dake (stdake) :
>
>> My vote is for option 2 to deprecate Debian as there has been very little
>> activity and operators seem uninterested in Debian as a platform.
>>
>> We could always add it back in at a later date if operators were to
>> request it and the Debian team were interested in maintaining it.
>>
>> Regards
>> -steve
>>
>>
>> -Original Message-
>> From: Christian Berendt 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Date: Thursday, January 19, 2017 at 3:53 AM
>> To: "openstack-dev@lists.openstack.org" > .org>
>> Subject: [openstack-dev] [vote][kolla] deprecation for Debian distro
>> support
>>
>> As discussed in one of the last team meetings I want to propose the
>> deprecation (this cycle) and removal (next cycle) of the Debian support in
>> Kolla.
>>
>> More than 1 week ago I sent a pre warning mail to the
>> openstack-operators mailing list, without any reply [0].
>>
>> Kolla core reviewers, please vote now. The vote will be open for 7
>> days (26.01.2017).
>>
>> 1. Kolla needs support for Debian, it should not be deprecated
>>
>> 2. Kolla should deprecate support for Debian
>>
>> [0] http://lists.openstack.org/pipermail/openstack-operators/201
>> 7-January/012427.html
>>
>> --
>> Christian Berendt
>> Chief Executive Officer (CEO)
>>
>> Mail: bere...@betacloud-solutions.de
>> Web: https://www.betacloud-solutions.de
>>
>> Betacloud Solutions GmbH
>> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>>
>> Geschäftsführer: Christian Berendt
>> Unternehmenssitz: Stuttgart
>> Amtsgericht: Stuttgart, HRB 756139
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Davanum Srinivas]

"keystoneauth1 >= 2.17.0" implies python-novaclient with your fix will
work for any version including 2.17.0 which is not true. you need to
either do "keystoneauth1 >= 2.18.0" or "keystoneauth1 > 2.17.0" and we
prefer the ">=" notation i think.

Thanks,
Dims

On Fri, Jan 20, 2017 at 10:53 PM, Kekane, Abhishek
 wrote:
> Hi Dims,
>
> Thank you for reply. I will propose a patch soon. Just for curiosity,
> keystoneauth1 >= 2.17.0 will not install 2.18.0?
>
> Abhishek
> 
> From: Davanum Srinivas 
> Sent: Saturday, January 21, 2017 8:27:56 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [ python-novaclient][ python-glanceclient][
> python-cinderclient][ python-neutronclient] Remove x-openstack-request-id
> logging code as it is logged twice
>
> Abhishek,
>
> 1) requirements.txt for all 4 python-*client you mentioned have
> "keystoneauth1>=2.17.0",
> 2) i do not see a review request to bump the minimum version in global
> requirements for keystoneauth1 to "keystoneauth1>=2.18.0"
> (https://review.openstack.org/#/q/project:openstack/requirements+is:open)
>
> Can you please file one?
>
> Thanks,
> Dims
>
>
> On Fri, Jan 20, 2017 at 12:52 AM, Kekane, Abhishek
>  wrote:
>> Hi Devs,
>>
>>
>>
>> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is
>> logged
>> for every HTTP response. This keystoneauth1 version will be used for
>> ocata.
>>
>> The same request id is also logged in 'request' method of SessionClient
>> class for python-novaclient, python-glanceclient, python-cinderclient and
>> python-neutronclient. Once requirements.txt is synced with
>> global-requirements and it uses keystoneauth1 version 2.18.0 and above,
>> x-openstack-request-id will be logged twice for these clients.
>>
>>
>>
>> I have submitted patches for python-novaclient [1] and python-glanceclient
>> [2] and created patches for python-cinderclient and python-neutronclient
>> but
>> same will not be reviewed unless and until the requirements.txt is synced
>> with global-requirements and it uses keystoneauth1 version 2.18.0.
>>
>>
>>
>> As final releases for client libraries are scheduled in the next week
>> (between Jan 23 - Jan 27) we want to address these issues in the above
>> mentioned clients.
>>
>>
>>
>> Please let us know your opinion about the same.
>>
>>
>>
>> [1] https://review.openstack.org/422602
>>
>> [2] https://review.openstack.org/422591
>>
>>
>> __
>> Disclaimer: This email and any attachments are sent in strictest
>> confidence
>> for the sole use of the addressee and may contain legally privileged,
>> confidential, and proprietary data. If you are not the intended recipient,
>> please advise the sender by replying promptly to this email and then
>> delete
>> and destroy this email and any attachments without any further use,
>> copying
>> or forwarding.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Kekane, Abhishek]

Hi Steve,

Thank you for the update. I have already submitted patches for 
python-novaclient and python-novaclient for reviews and ready with 
python-cinderclient and python-novaclient patches. I will submit them ASAP when 
requirements.txt is synced with updated version of keystoneauth1.

Thank you,

Abhishek

From: Steve Martinelli 
Sent: Saturday, January 21, 2017 10:07:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ 
python-cinderclient][ python-neutronclient] Remove x-openstack-request-id 
logging code as it is logged twice



On Fri, Jan 20, 2017 at 10:53 PM, Kekane, Abhishek 
> wrote:
Hi Dims,

Thank you for reply. I will propose a patch soon. Just for curiosity, 
keystoneauth1 >= 2.17.0 will not install 2.18.0?

It will, but if we make 2.18.0 the minimum then it will for sure install only 
that level.

> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is logged
> for every HTTP response. This keystoneauth1 version will be used for ocata.
>
> The same request id is also logged in 'request' method of SessionClient
> class for python-novaclient, python-glanceclient, python-cinderclient and
> python-neutronclient. Once requirements.txt is synced with
> global-requirements and it uses keystoneauth1 version 2.18.0 and above,
> x-openstack-request-id will be logged twice for these clients.

So I approved this change (sorry it took so long to review and merge), but I 
didn't realize it was going to impact python-{nova | glance | cinder | 
neutron}client. I think it's slightly unrealistic to ask four teams to remove 
the logging in the last week we release clients (I'm assuming we want to remove 
the functionality and not log things twice).

 - Would folks prefer I revert the keystoneauth change and re-release without 
it, and we can bring it back in Pike?
- Do teams have the bandwidth to remove the request id logging in the next few 
days?

Sorry for the confusion this caused.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [telemetry][ptl] Candidacy for Pike

[Julien Danjou]

Hi!

As I can observe every end of cycle, the Telemetry team has been doing an
amazing job making progress on the projects we manage this cycle. Gnocchi
gained features and traction, Aodh got new contributors, Panko started his own
destiny and Ceilometer is reducing and improving its footprint.

If you look at the release goals that have been decided or are being discussed
(Python 3.5, mod_wsgi deployment, oslo usage…), you will notice our projects
are way ahead and I think it's tremendous. And our team is continuously
improving the rest of OpenStack by contributing to Oslo too. I reiterate what I
said last cycle: think it's a great achievement for a small team like us.

So, yes, I envision us continuing on this trajectory, setting the bar higher
for everyone. That's why I'm running again this time to serve the team,
managing the project in a transparent way and do everything I can to grow our
community and make people feel welcome.

We all know how barely useful we made the PTL be, and I count on keeping it
that way. :-)

Happy hacking,

(For reference, review: https://review.openstack.org/#/c/423125/)

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Atlanta PTG

[Michele Baldessari]

Hi Emilien,

while not a design session per se, I would love to propose a short slot
for TripleO CI Q, if we have some time left. In short, I'd like to be
more useful around CI failures, but I lack the understanding of a few
aspects of our current CI (promotion, when do images get built, etc.),
that would benefit quite a bit from a short session where we have a few
CI folks in the room that could answer questions or give some tips.
I know of quite few other people that are in the same boat and maybe
this will help a bit our current issue where only a few folks always
chase CI issues.

If there is consensus (and some CI folks willing to attend ;) and time
for this, I'll be happy to organize this and prepare a bunch of
questions ideas beforehand.

Thoughts?
Michele

On Wed, Jan 04, 2017 at 07:26:52AM -0500, Emilien Macchi wrote:
> I would like to bring this topic up on your inbox, so we can continue
> to make progress on the agenda. Feel free to follow existing examples
> in the etherpad and propose a design dession.
> 
> Thanks,
> 
> On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi  wrote:
> > General infos about PTG: https://www.openstack.org/ptg/
> >
> > Some useful informations about PTG/TripleO:
> >
> > * When? We have a room between Wednesday and Friday included.
> > Important sessions will happen on Wednesday and Thursday. We'll
> > probably have sessions on Friday, but it might be more hands-on and
> > hackfest, where people can enjoy the day to work together.
> >
> > * Let's start to brainstorm our topics:
> > https://etherpad.openstack.org/p/tripleo-ptg-pike
> >   Feel free to add any topic, as soon as you can. We need to know asap
> > which sessions will be share with other projects (eg: tripleo/mistral,
> > tripleo/ironic, tripleo/heat, etc).
> >
> >
> > Please let us know any question or feedback,
> > Looking forward to seeing you there!
> > --
> > Emilien Macchi
> 
> 
> 
> -- 
> Emilien Macchi
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

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

[openstack-dev] [ironic-pyhon-agent][DIB] IPA failed to start on Ubuntu because of modprobe path

[Moshe Levi]

Hi,
This commit 
https://github.com/openstack/diskimage-builder/commit/2854f4063bd2a6dcdb6fa5fab93aa56857e47b59
 
Added ExecStartPre=/usr/sbin/modprobe vfat to the ironic-python-agent systemd 
script 
The problem is that modprobe location in Ubuntu / sbin/modprobe (the 
/usr/sbin/modprobe vfat works for redhat)
I have opened this bug in Launchpad 
https://bugs.launchpad.net/diskimage-builder/+bug/1658297  
This break IPA element when building with Ubunut OS.
Is there conditional in systemd scripts like 
If os == Redhat then
ExecStartPre=/usr/sbin/modprobe vfat
Elseif os == Ubuntu  then
ExecStartPre=/sbin/modprobe vfat

What is the best way to fix this? 

Thanks,
Moshe Levi



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

Re: [openstack-dev] [cinder] Can I use lvm thin provisioning in mitaka?

[Marco Marino]

Really thank you!! It's difficult for me find help on cinder and I think
this is the right place!
@Duncan, if my goal is to speeding up bootable volume creation, I can avoid
to use thin provisioning. I can use image cache and in this way the
"retrieve from glance" and the "qemu-img convert to RAW" parts will be
skipped. Is this correct? And whit this method I don't have a performancy
penalty mentioned by Chris.
@Chris: Yes, I'm using volume_clear option and volume deletion is very fast

Marco



2017-01-20 18:24 GMT+01:00 Duncan Thomas :

> There's also cinder functionality called the 'generic image cache' that
> does this for you; see the (per-backend) config options:
> image_volume_cache_enabled, image_volume_cache_max_size_gb and
> image_volume_cache_max_count
>
> On 20 January 2017 at 16:54, Chris Friesen 
> wrote:
>
>> On 01/20/2017 04:07 AM, Marco Marino wrote:
>>
>>> Hi, I'm trying to use cinder with lvm thin provisioning. It works well
>>> and I'd
>>> like to know if there is some reason lvm thin should be avoided in mitaka
>>> release. I'm trying to use with
>>> max_over_subscription_ratio = 1.0
>>> so I don't have problems with over subscription.
>>> I using thin provisioning because it is fast (I think). More precisely,
>>> my use
>>> case is:
>>>
>>> - create one bootable volume. This is a long operation because cinder
>>> download
>>> the image from glance, qemu-img convert in raw format and then "dd" copy
>>> the
>>> image in the volume.
>>> - Create a snapshot of the bootable volume. Really fast and reliable
>>> because the
>>> original volume is not used by any vm.
>>> - Create a new volume from the snapshot. This is faster than create a new
>>> bootable volume.
>>>
>>> Is this use correct? Can I deploy in the production environment (mitaka
>>> - centos 7)
>>> Thank you
>>>
>>
>> For what it's worth we're using cinder with LVM thin provisioning in
>> production with no overprovisioning.
>>
>> What you're proposing should work, you're basically caching the vanilla
>> image as a cinder snapshot.
>>
>> If you wish to speed up volume deletion, you can set "volume_clear=none"
>> in the cinder.conf file.
>>
>> Be aware that LVM thin provisioning will see a performance penalty the
>> first time you write to a given disk block in a volume, because it needs to
>> allocate a new block, zero it out, then write the new data to it.
>>
>> Chris
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> --
> Duncan Thomas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev