Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

Thanks Clint! On Mon, Feb 27, 2017 at 2:41 AM, Clint Byrum wrote: > Excerpts from Shamail Tahir's message of 2017-02-27 00:44:44 -0500: > > Hi Clint, > > > > On Mon, Feb 27, 2017 at 12:25 AM, Clint Byrum wrote: > > > > > Excerpts from Matt Riedemann's

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

Excerpts from Shamail Tahir's message of 2017-02-27 00:44:44 -0500: > Hi Clint, > > On Mon, Feb 27, 2017 at 12:25 AM, Clint Byrum wrote: > > > Excerpts from Matt Riedemann's message of 2017-02-26 19:48:50 -0600: > > > On 2/26/2017 6:52 PM, Clint Byrum wrote: > > > > During

Re: [openstack-dev] [QA]Refactoring Scenarios manager.py

On Mon, 27 Feb 2017, 12:32 a.m. Ghanshyam Mann, wrote: > Yea, there is no doubt we should refactor scenario tests but even those > are internal interface it breaks plugins. We can argue that plugins should > not be using those but before that tempest should have all

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

Hi Clint, On Mon, Feb 27, 2017 at 12:25 AM, Clint Byrum wrote: > Excerpts from Matt Riedemann's message of 2017-02-26 19:48:50 -0600: > > On 2/26/2017 6:52 PM, Clint Byrum wrote: > > > During some productive discussions in the Stewardship Working Group PTG > > > room, the

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

Excerpts from Matt Riedemann's message of 2017-02-26 19:48:50 -0600: > On 2/26/2017 6:52 PM, Clint Byrum wrote: > > During some productive discussions in the Stewardship Working Group PTG > > room, the subject of the mailing list came up. The usual questions > > around whether or not we should

Re: [openstack-dev] [QA]Refactoring Scenarios manager.py

First I really appreciate Jordan's work, and I always appreciate those who really do something. If we don't have a begining, then we will never reach the end. I now sort out the problem as: 1) Do we need to refactory the Tempest scenario code? -- yes 2) What if scenario refactory

Re: [openstack-dev] [keystone]PKI token VS Fernet token

Thank you all very much, the less data to be replicated, the better. Best Regards Chaoyi Huang (joehuang) From: Clint Byrum [cl...@fewbar.com] Sent: 26 February 2017 12:06 To: openstack-dev Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

On 2/26/2017 6:52 PM, Clint Byrum wrote: During some productive discussions in the Stewardship Working Group PTG room, the subject of the mailing list came up. The usual questions around whether or not we should have per-project lists came up and the reasons we don't were re-affirmed. To recap

[openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

During some productive discussions in the Stewardship Working Group PTG room, the subject of the mailing list came up. The usual questions around whether or not we should have per-project lists came up and the reasons we don't were re-affirmed. To recap those reasons: * Cross posting is the

Re: [openstack-dev] [QA]Refactoring Scenarios manager.py

Yea, there is no doubt we should refactor scenario tests but even those are internal interface it breaks plugins. We can argue that plugins should not be using those but before that tempest should have all required interface/class/helper as stable interface for plugins. which is what scenario

Re: [openstack-dev] [QA]Refactoring Scenarios manager.py

On Sun, Feb 26, 2017 at 12:49 AM Masayuki Igawa wrote: > Hi, > > Thank you for bringing this up. > > Yeah, I understand your frustration. We already have the document about > our stable interface[1]. It says > -- > Stability > Any code that lives in tempest/lib will be

[openstack-dev] [storlets] PTG summary

Hi, I have wrote a summary for the discussions we had in the Etherpad [1] there is a summary section under each of the topics. Otherwise, I will not be able to attend the meeting this Tuesday as I will be on a flight back from the US. Thanks, Eran [1]

Re: [openstack-dev] [keystone][api] Changing devstack to not set up keystone on :5000 and :35357

On Sat, Feb 25, 2017 at 1:10 PM, Lance Bragstad wrote: > Nice! Thanks for revisiting this, Brant. > > Was this a cross-project goal/discussion at the PTG? > I attended the cross-project discussion about the service catalog. There might have also been some discussion at an

Re: [openstack-dev] [nova][cinder] Schedule Instances according to Local disk based Volume?

On Thu, Feb 23, 2017 at 7:18 PM, Zhenyu Zheng wrote: > Matt, > > Thanks for the information, I will check that; But still I think the user > demand here is to use local disk from > compute node as block device, as the data can be remained if the old vm > got deleted,

Re: [openstack-dev] [Ceilometer] Threshold alarm for multiple instance

Thanks Julien, I have one more question, How can I export meters to udp? I config udp:// in pipeline.yaml, and using a python script for receiving UDP packet, but nothing happen: pipeline.yaml: http://prntscr.com/edl6ll udp_receive.py: http://paste.openstack.org/show/600507/ 2017-02-26 17:40

Re: [openstack-dev] [Ceilometer] Threshold alarm for multiple instance

On Sun, Feb 26 2017, Sam Huracan wrote: > This log tells me there is an instance reach threshold, but I do not know > exactly what instance. You've got the alarm_id so ultimately it's up to your application to know? > I want create threshold alarm for all instances in my system, which alarms >

[openstack-dev] [Ceilometer] Threshold alarm for multiple instance

Hi, I create a network threshold alarm, I get alarm through webhook as follow: 10.193.0.22 - - [26/Feb/2017 16:30:23] "POST /network HTTP/1.1" 200 - {u'severity': u'low', u'alarm_name': u'in_bandwidth', u'current': u'alarm', u'alarm_id': u'e367dce6-2651-4fc9-aae5-1366a22db889', u'reason':