Re: [openstack-dev] [Watcher] Nominating licanwei to Watcher Core

[Prashanth Hari]

+1

On Wed, Feb 15, 2017 at 6:27 AM, Antoine Cabot 
wrote:

> +1
>
> On Tue, Feb 14, 2017 at 5:57 PM, Jean-Émile DARTOIS <
> jean-emile.dart...@b-com.com> wrote:
>
>> ​+1
>>
>>
>> Jean-Emile
>> DARTOIS
>>
>> {P} Software Engineer
>> Cloud Computing
>> {T} +33 (0) 2 56 35 8260
>> {W} www.b-com.com
>> --
>> *De :* Susanne Balle 
>> *Envoyé :* mardi 14 février 2017 17:33
>> *À :* OpenStack Development Mailing List (not for usage questions)
>> *Objet :* Re: [openstack-dev] [Watcher] Nominating licanwei to Watcher
>> Core
>>
>> +1
>>
>> On Tue, Feb 14, 2017 at 5:37 AM, Vincent FRANÇOISE <
>> vincent.franco...@b-com.com> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> +1
>>>
>>> On 14/02/2017 11:27, ? ? wrote:
>>> > His activity will help Watcher Team to make this project better.
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2.0.22 (GNU/Linux)
>>>
>>> iQEcBAEBAgAGBQJYot3aAAoJEEb+XENQ/jVSvIEH/RsqFZZ7hZyA7ExieF7K4GmN
>>> d1f1vnPbOR3MgqQTbezixIPIwzrDw9dtpU6q8BRPARP6ja2tOPNoYHc1CZmxgwz9
>>> Mc5iVhvAaKuzL7KKpeROVkLkVUJ9bZnxNM/pkgiq0qXYoBaitgVdPVTIE6nBLdpV
>>> yHRkUG24pkojogIJGIbB2cJeKganJ+PrCB59buAof1NqEhujt00akfjHCKbc7Wc/
>>> oSmx2VD3aRn8OcfAhQ1pQgRYpa6MRFBRbDUPejVyiGzFWTDreWA3cLVq2xpGEcCW
>>> ahcq2MNsZCiFegD4u9jYroULOALhdGBUctONbluaqbfZ7PhPPqQxSJGQq96hTCg=
>>> =WsCi
>>> -END PGP SIGNATURE-
>>>
>>> 
>>> __
>>> 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
>
>
__
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] [Watcher] Nominating Prudhvi Rao Shedimbi to Watcher Core

[Prashanth Hari]

+1

On Tue, Feb 14, 2017 at 9:22 AM, Joe Cropper  wrote:

> +1 !
>
> > On Feb 14, 2017, at 4:05 AM, Vincent FRANÇOISE <
> vincent.franco...@b-com.com> wrote:
> >
> > Team,
> >
> > I would like to promote Prudhvi Rao Shedimbi to the core team. He's done
> > a great work in reviewing many patchsets[1] and I believe that he has a
> > good vision of Watcher as a whole.
> >
> > I think he would make an excellent addition to the team.
> >
> > Please vote
> >
> > [1] http://stackalytics.com/report/contribution/watcher/90
> >
> > Vincent FRANCOISE
> > B<>COM
> >
> > 
> __
> > 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

Re: [openstack-dev] [Watcher] Promote Alexchadin to the core team.

[Prashanth Hari]

+1

On Wed, Aug 10, 2016 at 4:13 AM, Antoine Cabot 
wrote:

> +1
>
> On Thu, Aug 4, 2016 at 9:29 AM, Vincent FRANÇOISE
>  wrote:
> > Alexander Chadin did prove he knew the various moving parts of Watcher
> > by participating the numerous design discussions and blueprints during
> > the last months which makes him a precious asset for our team.
> >
> > So that's a definite +1 for me as well.
> >
> >
> > On 04/08/2016 09:11, Jean-Émile DARTOIS wrote:
> >> Hi all,
> >>
> >> alexchadin has consistently contributed to Watcher for a while. He is
> >> also very active on IRC. Based on his contribution (e.g:
> >> continuously-optimization blueprint) and expertise which adds concrete
> >> value to Watcher, I’d like to promote alexchadin to the core team.
> >>
> >> According to the OpenStack Governance process [1], Please vote +1 or -1
> >> to the nomination.
> >>
> >> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> >>
> >> Best regards,
> >>
> >> jed56
> >>
> >>
> >> Jean-Emile
> >> DARTOIS
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 
> __
> >> 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
>
__
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] [ceilometer]Handling cumulative counter resets

[Prashanth Hari]

Julien,

Again, how are we validating this in Gnocchi ?

Thanks,
Prashanth

On Thu, Apr 16, 2015 at 3:45 AM, Julien Danjou jul...@danjou.info wrote:

 On Wed, Apr 15 2015, Prashanth Hari wrote:

  Can someone please provide some info on how we are handling cumulative
  counter resets for various scenarios in ceilometer ?
 
  Seeing some old posts and bugs but couldn't find any references to fixes
 -
  https://bugs.launchpad.net/ceilometer/+bug/1061817
 
 http://openstack.10931.n7.nabble.com/ceilometer-The-reset-on-the-cumulative-counter-td3275.html
 
  Is this still an open issue ?

 Yes, but the issue is becoming deprecated as we know have Gnocchi¹
 available as a backend who can handle those meter types without issue.


 ¹  http://launchpad.net/gnocchi

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

__
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] [ceilometer]Handling cumulative counter resets

[Prashanth Hari]

Hi,

Can someone please provide some info on how we are handling cumulative
counter resets for various scenarios in ceilometer ?

Seeing some old posts and bugs but couldn't find any references to fixes -
https://bugs.launchpad.net/ceilometer/+bug/1061817
http://openstack.10931.n7.nabble.com/ceilometer-The-reset-on-the-cumulative-counter-td3275.html

Is this still an open issue ?

Thanks,
Prashanth
__
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] [Openstack-dev][tempest] Jenkins failure unrelated to my patch

[Prashanth Hari]

Hi,

Jenkins failing for a scenario test case patch which I submitted -
https://review.openstack.org/#/c/102827/

The failures are unrelated to my changes.

Can someone please look into this ?


2014-06-26 14:47:00.948 |
2014-06-26 14:47:00.948 |
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]
2014-06-26 14:47:00.948 |
--
2014-06-26 14:47:00.948 |
2014-06-26 14:47:00.949 | Captured traceback:
2014-06-26 14:47:00.949 | ~~~
2014-06-26 14:47:00.949 | Traceback (most recent call last):
2014-06-26 14:47:00.949 |   File tempest/test.py, line 127, in wrapper
2014-06-26 14:47:00.949 | return f(self, *func_args, **func_kwargs)
2014-06-26 14:47:00.949 |   File
tempest/scenario/test_volume_boot_pattern.py, line 161, in
test_volume_boot_pattern
2014-06-26 14:47:00.949 | keypair)
2014-06-26 14:47:00.949 |   File
tempest/scenario/test_volume_boot_pattern.py, line 102, in _ssh_to_server
2014-06-26 14:47:00.949 | floating_ip =
self.compute_client.floating_ips.create()
2014-06-26 14:47:00.949 |   File
/opt/stack/new/python-novaclient/novaclient/v1_1/floating_ips.py, line
44, in create
2014-06-26 14:47:00.950 | return self._create(/os-floating-ips,
{'pool': pool}, floating_ip)
2014-06-26 14:47:00.950 |   File
/opt/stack/new/python-novaclient/novaclient/base.py, line 152, in _create
2014-06-26 14:47:00.950 | _resp, body = self.api.client.post(url,
body=body)
2014-06-26 14:47:00.950 |   File
/opt/stack/new/python-novaclient/novaclient/client.py, line 330, in post
2014-06-26 14:47:00.950 | return self._cs_request(url, 'POST',
**kwargs)
2014-06-26 14:47:00.950 |   File
/opt/stack/new/python-novaclient/novaclient/client.py, line 304, in
_cs_request
2014-06-26 14:47:00.950 | **kwargs)
2014-06-26 14:47:00.950 |   File
/opt/stack/new/python-novaclient/novaclient/client.py, line 286, in
_time_request
2014-06-26 14:47:00.950 | resp, body = self.request(url, method,
**kwargs)
2014-06-26 14:47:00.950 |   File
/opt/stack/new/python-novaclient/novaclient/client.py, line 280, in
request
2014-06-26 14:47:00.951 | raise exceptions.from_response(resp,
body, url, method)
2014-06-26 14:47:00.951 | NotFound: No more floating ips available.
(HTTP 404) (Request-ID: req-6d052d87-8162-48da-8a57-75145cdf91a9)
2014-06-26 14:47:00.951 |


2014-06-26 14:12:31.960 | tearDownClass
(tempest.api.baremetal.test_ports_negative.TestPortsNegative)
2014-06-26 14:12:31.960 |
---
2014-06-26 14:12:31.960 |
2014-06-26 14:12:31.960 | Captured traceback:
2014-06-26 14:12:31.960 | ~~~
2014-06-26 14:12:31.960 | Traceback (most recent call last):
2014-06-26 14:12:31.960 |   File tempest/api/baremetal/base.py, line
66, in tearDownClass
2014-06-26 14:12:31.960 | delete_method(u,
ignore_errors=exc.NotFound)
2014-06-26 14:12:31.960 |   File tempest/services/baremetal/base.py,
line 37, in wrapper
2014-06-26 14:12:31.960 | return f(*args, **kwargs)
2014-06-26 14:12:31.960 |   File
tempest/services/baremetal/v1/base_v1.py, line 160, in delete_node
2014-06-26 14:12:31.961 | return self._delete_request('nodes', uuid)
2014-06-26 14:12:31.961 |   File tempest/services/baremetal/base.py,
line 167, in _delete_request
2014-06-26 14:12:31.961 | resp, body = self.delete(uri)
2014-06-26 14:12:31.961 |   File tempest/common/rest_client.py, line
224, in delete
2014-06-26 14:12:31.961 | return self.request('DELETE', url,
extra_headers, headers, body)
2014-06-26 14:12:31.961 |   File tempest/common/rest_client.py, line
430, in request
2014-06-26 14:12:31.961 | resp, resp_body)
2014-06-26 14:12:31.961 |   File tempest/common/rest_client.py, line
484, in _error_checker
2014-06-26 14:12:31.961 | raise exceptions.Conflict(resp_body)
2014-06-26 14:12:31.961 | Conflict: An object with that identifier
already exists
2014-06-26 14:12:31.961 | Details: {u'error_message': u'{debuginfo:
null, faultcode: Client, faultstring: Node
9c75225e-24b7-48e6-a5f4-8f9fd4ec5691 is locked by host localhost, please
retry after the current operation is completed.\\nTraceback (most recent
call last):\\n\\n  File
\\/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/server.py\\,
line 137, in inner\\nreturn func(*args, **kwargs)\\n\\n  File
\\/opt/stack/new/ironic/ironic/conductor/manager.py\\, line 811, in
destroy_node\\nwith task_manager.acquire(context, node_id) as
task:\\n\\n  File
\\/opt/stack/new/ironic/ironic/conductor/task_manager.py\\, line 112, in
acquire\\ndriver_name=driver_name)\\n\\n  File
\\/opt/stack/new/ironic/ironic/conductor/task_manager.py\\, line 160, in
__init__\\nself.release_resources()\\n\\n  

Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed.

[Prashanth Hari]

Hi,

We have updated the operators data -
https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1

Please note the percentage is based on number of VIPs. The traffic
distribution (connections / sec) will vary by services.

Thanks,
Prashanth
Comcast




On Wed, Apr 9, 2014 at 11:28 AM, Susanne Balle sleipnir...@gmail.comwrote:

 Hi



 I wasn't able to get % for the spreadsheet but our Product Manager
 prioritized the features:



 *Function*

 *Priority (0 = highest)*

 *HTTP+HTTPS on one device*

 5

 *L7 Switching*

 2

 *SSL Offloading*

 1

 *High Availability*

 0

 *IP4  IPV6 Address Support*

 6

 *Server Name Indication (SNI) Support*

 3

 *UDP Protocol*

 7

 *Round Robin Algorithm*

 4



  Susanne


 On Thu, Apr 3, 2014 at 9:32 AM, Vijay Venkatachalam 
 vijay.venkatacha...@citrix.com wrote:



 The document has Vendor  column, it should be from Cloud
 Operator?



 Thanks,

 Vijay V.





 *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com]
 *Sent:* Thursday, April 3, 2014 11:23 AM
 *To:* OpenStack Development Mailing List (not for usage questions)

 *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Load balancing use
 cases. Data from Operators needed.



 Stephen,



 Agree with you. Basically the page starts looking as requirements page.

 I think we need to move to google spreadsheet, where table is organized
 easily.

 Here's the doc that may do a better job for us:


 https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWcusp=sharing



 Thanks,

 Eugene.



 On Thu, Apr 3, 2014 at 5:34 AM, Prashanth Hari hvpr...@gmail.com wrote:

  More additions to the use cases (
 https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases).

 I have updated some of the features we are interested in.







 Thanks,

 Prashanth





 On Wed, Apr 2, 2014 at 8:12 PM, Stephen Balukoff sbaluk...@bluebox.net
 wrote:

  Hi y'all--



 Looking at the data in the page already, it looks more like a feature
 wishlist than actual usage data. I thought we agreed to provide data based
 on percentage usage of a given feature, the end result of the data
 collection being that it would become more obvious which features are the
 most relevant to the most users, and therefore are more worthwhile targets
 for software development.



 Specifically, I was expecting to see something like the following (using
 hypothetical numbers of course, and where technical people from Company A
  etc. fill out the data for their organization):



 == L7 features ==



 Company A (Cloud operator serving external customers): 56% of
 load-balancer instances use

 Company B (Cloud operator serving external customers): 92% of
 load-balancer instances use

 Company C (Fortune 100 company serving internal customers): 0% of
 load-balancer instances use



 == SSL termination ==



 Company A (Cloud operator serving external customers): 95% of
 load-balancer instances use

 Company B (Cloud operator serving external customers): 20% of
 load-balancer instances use

 Company C (Fortune 100 company serving internal customers): 50% of
 load-balancer instances use.



 == Racing stripes ==



 Company A (Cloud operator serving external customers): 100% of
 load-balancer instances use

 Company B (Cloud operator serving external customers): 100% of
 load-balancer instances use

 Company C (Fortune 100 company serving internal customers): 100% of
 load-balancer instances use





 In my mind, a wish-list of features is only going to be relevant to this
 discussion if (after we agree on what the items under consideration ought
 to be) each technical representative presents a prioritized list for their
 organization. :/ A wish-list is great for brain-storming what ought to be
 added, but is less relevant for prioritization.



 In light of last week's meeting, it seems useful to list the features
 most recently discussed in that meeting and on the mailing list as being
 points on which we want to gather actual usage data (ie. from what people
 are actually using on the load balancers in their organization right now).
 Should we start a new page that lists actual usage percentages, or just
 re-vamp the one above?  (After all, wish-list can be useful for discovering
 things we're missing, especially if we get people new to the discussion to
 add their $0.02.)



 Thanks,

 Stephen







 On Wed, Apr 2, 2014 at 3:46 PM, Jorge Miramontes 
 jorge.miramon...@rackspace.com wrote:

   Thanks Eugene,



 I added our data onto the requirements page since I was hoping to
 prioritize requirements based on the operator data that gets provided. We
 can move it over to the other page if you think that makes sense. See
 everyone on the weekly meeting tomorrow!



 Cheers,

 --Jorge



 *From: *Susanne Balle sleipnir...@gmail.com
 *Reply-To: *OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 *Date: *Tuesday, April 1, 2014 4:09 PM

[openstack-dev] [Neutron][LBaaS] LBaaS design proposals

[Prashanth Hari]

Hi,

I am a late comer in this discussion.
Can someone please point me to the design proposal documentations in
addition to the object model ?


Thanks,
Prashanth
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

[Prashanth Hari]

Same here.. will be interested to join.

Thanks,
Prashanth


On Thu, Mar 6, 2014 at 11:51 AM, Veiga, Anthony 
anthony_ve...@cable.comcast.com wrote:


 On Thu, 2014-03-06 at 15:32 +, Jorge Miramontes wrote:
  I'd like to gauge everyone's interest in a possible mini-summit for
  Neturon LBaaS. If enough people are interested I'd be happy to try and
  set something up. The Designate team just had a productive mini-summit
  in Austin, TX and it was nice to have face-to-face conversations with
  people in the Openstack community. While most of us will meet in
  Atlanta in May, I feel that a focused mini-summit will be more
  productive since we won't have other Openstack distractions around us.
  Let me know what you all think!
 
 ++
 
 ++
 
 I think a few weeks after the design summit would be a good time.
 
 -jay
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 Throwing my hat into the ring as well. I think this would be quite useful.
 -Anthony


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev