Re: [openstack-dev] [telemetry] stepping down as PTL

[Jason Myers]

You will be greatly missed! Thank you for showing me the ropes, and working
so hard to improve telemetry!

Cheers,
Jason

On Friday, March 11, 2016, gordon chung  wrote:

> hi folks,
>
> as the PTL nominations are open, i just want to note that i won't be
> running again as the Telemetry PTL for Newton cycle.
>
> i've thoroughly enjoyed my time as PTL which afforded me the opportunity
> to work with and learn from some great individuals who share the same
> passion to collaborate openly. i have the utmost confidence that the
> projects will continue to grow and become more refined under the next
> leadership.
>
> personal thanks to everyone in Aodh, Ceilometer and Gnocchi communities
> as well as the projects that provided valuable feedback by collaborating
> with us. i thank you for sharing in the decision making so i could
> spread the blame around. i also thank you for reading through terribly
> written messages that make you question whether the shift keys on all my
> keyboards are broken.
>
> cheers,
>
> --
> gord
> __
> 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-dev] Ceilometer M Midcycle

[Jason Myers]

Hello Everyone,
We are setting up a few polls to determine the possibility of 
meeting face to face for a ceilometer midcycle in Dublin, IE. We'd like 
to gather for three days to discuss all the work we are currently doing; 
however, we have access to space for 5 so you could also use that space 
for co working outside of the meeting dates.  We have two date polls: 
one for Nov 30-Dec 18 at http://doodle.com/poll/hmukqwzvq7b54cef, and 
one for Jan 11-22 at http://doodle.com/poll/kbkmk5v2vass249i.  You can 
vote for any of the days in there that work for you.  If we don't get 
enough interest in either poll, we will do a virtual midcycle like we 
did last year.  Please vote for your favorite days in the two polls if 
you are interested in attending in person. If we don't get many votes, 
we'll circulate another poll for the virtual dates.


Cheers,
Jason Myers
--
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
__
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] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

[Jason Myers]

I enjoy using validictory for using Jsonschema with Python 
https://pypi.python.org/pypi/validictory.

Sent from my iPhone

 On Aug 28, 2015, at 11:29 AM, Jay Pipes jaypi...@gmail.com wrote:
 
 On 08/28/2015 07:22 AM, Chris Dent wrote:
 
 This morning I kicked off a quick spec for replacing WSME in
 Ceilometer with ... something:
 
 https://review.openstack.org/#/c/218155/
 
 This is because not only is WSME not that great, it also results in
 controller code that is inscrutable.
 
 The problem with the spec is that it doesn't know what to replace
 WSME with.
 
 So, for your Friday afternoon pleasure I invite anyone with an
 opinion to hold forth on what framework they would choose. The spec
 lists a few options but please feel to not limit yourself to those.
 
 If you just want to shoot the breeze please respond here. If you
 have specific comments on the spec please response there.
 
 I'm not going to get into another discussion about what WSGI/routing 
 framework to use (go Falcon! ;) ). But, since you are asking specifically 
 about *validation* of request input, I'd like to suggest just using plain ol' 
 JSONSchema, and exposing the JSONSchema documents in a GET 
 /schemas/{object_type} resource endpoint.
 
 voluptuous may be more Pythonic, as Julien mentioned, but the problem is you 
 can't expose the validation schema to the end user via any standard document 
 format (like JSONSchema). Using the jsonschema library along with standard 
 JSONSchema documents allows the API to publish its expected request and 
 response schemas to the end user, allowing, for example, a client library to 
 pull the schema documents and utilize a JSONSchema parsing/validation library 
 locally to pre-validate data before ever sending it over the wire.
 
 Best,
 -jay
 
 __
 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] [nova][ceilometer] proposal to send bulk hypervisor stats data in periodic notifications

[Jason Myers]

I was involved in the IRC discussion, but to reiterate here this would
be a wonderful thing to get done. The current polling can be terribly
inefficient, and the ceilo team is already looking into other ways to
reduce the impact of it. I'm looking forward to helping with this.

Cheers,

Jason

On Wed, Jun 17, 2015, at 10:52 AM, Matt Riedemann wrote:
 Without getting into the details from the etherpad [1], a few of us in 
 IRC today were talking about how the ceilometer compute-agent polls 
 libvirt directly for guest VM statistics and how ceilometer should 
 really be getting this information from nova via notifications sent from 
 a periodic task in the nova compute manager.
 
 Nova already has the get_instance_diagnostics virt driver API which is 
 nice in that it has structured versioned instance diagnostic information 
 regardless of virt driver (unlike the v2 os-server-diagnostics API which 
 is a free-form bag of goodies depending on which virt driver is used, 
 which makes it mostly untestable and not portable).  The problem is the 
 get_instance_diagnostics virt driver API is per-instance, so it's not 
 efficient in the case that you want bulk instance data for a given 
 compute host.
 
 So the idea is to add a new virt driver API to get the bulk data and 
 emit that via a structured versioned payload similar to 
 get_instance_diagnostics but for all instances.
 
 Eventually the goal is for nova to send what ceilometer is collecting 
 today [2] and then ceilometer can just consume that notification rather 
 than doing the direct hypervisor polling it has today.
 
 Anyway, this is the high level idea, the details/notes are in the 
 etherpad along with next steps.
 
 Feel free to chime in now with reasons why this is crazy and will never 
 work and we shouldn't waste our time on it.
 
 [1] https://etherpad.openstack.org/p/nova-hypervisor-bulk-stats-notify
 [2] 
 http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-compute-meters.html
 
 -- 
 
 Thanks,
 
 Matt Riedemann
 
 
 __
 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