On 8/11/2014 4:22 PM, Eoghan Glynn wrote:
>
>> Hi Eoghan,
>>
>> Thanks for the note below. However, one thing the overview below does not
>> cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged. Many
>> folks feel that this technology is a viable solution for the problem space
>> d
On 8/11/2014 5:29 PM, Eoghan Glynn wrote:
>
>> On 8/11/2014 4:22 PM, Eoghan Glynn wrote:
Hi Eoghan,
Thanks for the note below. However, one thing the overview below does not
cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged.
Many
folks feel that thi
On 8/11/2014 6:49 PM, Eoghan Glynn wrote:
>
On 8/11/2014 4:22 PM, Eoghan Glynn wrote:
>> Hi Eoghan,
>>
>> Thanks for the note below. However, one thing the overview below does
>> not
>> cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged.
>> Many
>
Sounds very interesting. We're currently collecting detailed (and verified)
usage information in StackTach and are keen to see what CloudKitty is able to
offer. My one wish is that you keep the components as small pip
redistributables with low coupling to promote reuse with other projects. Many
On 8/14/2014 11:28 AM, Russell Bryant wrote:
> On 08/14/2014 10:04 AM, CARVER, PAUL wrote:
>> Daniel P. Berrange [mailto:berra...@redhat.com] wrote:
>>
>>> Depending on the usage needs, I think Google hangouts is a quite useful
>>> technology. For many-to-many session its limit of 10 participants c
Maybe we need to think about this from a distributed software perspective?
* Divide and Conquer?
Can we split the topics to create more manageable sub-groups? This way it's not
core-vs-non-core but intererested-vs-moderately-interested. (of course, this
is much the way the mailing list works)
On 8/14/2014 6:42 PM, Doug Hellmann wrote:
On Aug 14, 2014, at 4:41 PM, Joe Gordon
mailto:joe.gord...@gmail.com>> wrote:
On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann
mailto:d...@doughellmann.com>> wrote:
On Aug 13, 2014, at 3:05 PM, Eoghan Glynn
mailto:egl...@redhat.com>> wrote:
>
>>>
On 8/16/2014 10:09 AM, Chris Dent wrote:
> On Fri, 15 Aug 2014, Sandy Walsh wrote:
>
>> I recently suggested that the Ceilometer API (and integration tests)
>> be separated from the implementation (two repos) so others might plug
>> in a different implementation while m
On 8/18/2014 9:27 AM, Thierry Carrez wrote:
> Clint Byrum wrote:
>> Here's why folk are questioning Ceilometer:
>>
>> Nova is a set of tools to abstract virtualization implementations.
>> Neutron is a set of tools to abstract SDN/NFV implementations.
>> Cinder is a set of tools to abstract block-de
Hey y'all,
We've started a screencast series on the StackTach.v3 dev efforts [1]. It's
still early-days, so subscribe to the playlist for updates.
The videos start with the StackTach/Ceilometer integration presentation at the
Hong Kong summit, which is useful for background and motivation but t
Is there anything slated for the Paris summit around this?
I just spent nearly a week parsing Nova notifications and the pain of no schema
has overtaken me.
We're chatting with IBM about CADF and getting down to specifics on their
applicability to notifications. Once I get StackTach.v3 into pr
On 9/3/2014 11:32 AM, Chris Dent wrote:
> On Wed, 3 Sep 2014, Sandy Walsh wrote:
>
>> We're chatting with IBM about CADF and getting down to specifics on
>> their applicability to notifications. Once I get StackTach.v3 into
>> production I'm keen to get star
see them) [1] with the
advantages/disadvantages of each approach. It's just a strawman, so
bend/spindle/mutilate.
Look forward to feedback!
-S
[1] https://wiki.openstack.org/wiki/NotificationsAndCADF
On 9/3/2014 12:30 PM, Sandy Walsh wrote:
> On 9/3/2014 11:32 AM, Chris Dent wrote:
>&
For those of you playing the home game ... just added four new screencasts to
the StackTach.v3 playlist.
These are technical deep dives into the code added over the last week or so,
with demos.
For the more complex topics I spend a little time on the background and
rationale.
StackTach.v3:
> Jay Pipes - Wednesday, September 10, 2014 3:56 PM
>On 09/03/2014 11:21 AM, Sandy Walsh wrote:
>> On 9/3/2014 11:32 AM, Chris Dent wrote:
>>> I took some notes on this a few weeks ago and extracted what seemed
>>> to be the two main threads or ideas the were reveale
Seeing this thread reminded me:
We need support in the update script for entry points in olso setup.cfg to make
their way into the target project.
So, if update is getting some love, please keep that in mind.
___
OpenStack-dev mailing list
OpenStack-
+1 on the inline method. It makes it clear when a notification should be
emitted and, as you say, handles the exception handling better.
Also, if it makes sense for Horizon, consider bracketing long-running
operations in .start/.end pairs. This will help with performance tuning
and early error det
Hey!
We've ballparked that we need to store a million events per day. To that end,
we're flip-flopping between sql and no-sql solutions, hybrid solutions that
include elastic search and other schemes. Seems every road we go down has some
limitations. So, we've started working on test suite for
On 11/29/2013 11:41 AM, Julien Danjou wrote:
> On Fri, Nov 29 2013, Nadya Privalova wrote:
>
>> I'm very interested in performance results for Ceilometer. Now we have
>> successfully installed Ceilometer in the HA-lab with 200 computes and 3
>> controllers. Now it works pretty good with MySQL. O
he tests are underway. This will help with determining how many
collectors we need, where the bottlenecks are coming from, etc.
It might be nice to standardize on that so we can compare results?
-S
>
> Thanks,
> Nadya
>
>
>
> On Wed, Nov 27, 2013 at 9:42 PM, Sandy Walsh <ma
So, as I mention in the branch, what about deployments that haven't
transitioned to the library but would like to cherry pick this feature?
"after it starts moving into a library" can leave a very big gap when the
functionality isn't available to users.
-S
On 11/29/2013 03:58 PM, Doug Hellmann wrote:
>
>
>
> On Fri, Nov 29, 2013 at 2:14 PM, Sandy Walsh <mailto:sandy.wa...@rackspace.com>> wrote:
>
> So, as I mention in the branch, what about deployments that haven't
> transitioned to the library
On 12/01/2013 06:40 PM, Doug Hellmann wrote:
>
>
>
> On Sat, Nov 30, 2013 at 3:52 PM, Sandy Walsh <mailto:sandy.wa...@rackspace.com>> wrote:
>
>
>
> On 11/29/2013 03:58 PM, Doug Hellmann wrote:
> >
> >
> >
&
On 12/06/2013 03:45 PM, Dmitry Mescheryakov wrote:
> Hello all,
>
> We would like to push further the discussion on unified guest agent. You
> may find the details of our proposal at [1].
>
> Also let me clarify why we started this conversation. Savanna currently
> utilizes SSH to install/confi
)
Subject: [openstack-dev] [Ceilometer] Nomination of Sandy Walsh to core team
Hi There!
I¹m not 100% sure what the process is around electing an individual to the
core team (i.e., can a non-core person nominate someone?). However, I
believe the ceilometer core team could use a member who is more
On 12/18/2013 06:28 AM, Oleg Gelbukh wrote:
> I would copy that question. Looks like integration plan didn't work out,
> and healthnmon development either stalled or gone shadow..
>
> Anyone have information on that?
I think that's the case. There was no mention of Healthnmon at the last
summi
On 12/18/2013 01:44 PM, Nikola Đipanov wrote:
> On 12/18/2013 06:17 PM, Matt Riedemann wrote:
>>
>>
>> On 12/18/2013 9:42 AM, Matt Riedemann wrote:
>>> The question came up in this patch [1], how do we deprecate and remove
>>> keys in the notification payload? In this case I need to deprecate an
On 12/18/2013 03:00 PM, Russell Bryant wrote:
> We really need proper versioning for notifications. We've had a
> blueprint open for about a year, but AFAICT, nobody is actively working
> on it.
>
> https://blueprints.launchpad.net/nova/+spec/versioned-notifications
>
IBM is behind this effo
On 01/29/2014 11:50 AM, Swann Croiset wrote:
> Hi stackers,
>
> I would like to sharemy wonder here about Notifications.
>
> I'm working [1] on Heat notifications and I noticed that :
> 1/ Heat uses his context to store 'password'
> 2/ Heat and Nova store 'auth_token' in context too. Didn't ch
The notification system can specify multiple queues to publish to, so each of
your dependent services can feed from a separate queue.
However, this is a critical bug in oslo.messaging that has broken this feature.
https://bugs.launchpad.net/nova/+bug/1277204
Hopefully it'll get fixed quickly a
At the Nova mid-cycle meetup we've been talking about the problem of helping
new contributors. It got into a discussion of karma, code reviews, bug fixes
and establishing a name for yourself before screaming in a chat room "can
someone look at my branch". We want this experience to be positive,
This brings up something that's been gnawing at me for a while now ... why use
entry-point based loaders at all? I don't see the problem they're trying to
solve. (I thought I got it for a while, but I was clearly fooling myself)
1. If you use the "load all drivers in this category" feature, that
And sorry, as to your original problem, the loadables approach is kinda
messy since only the classes that are loaded when *that* module are
loaded are used (vs. explicitly specifying them in a config). You may
get different results when the flow changes.
Either entry-points or config would give re
On 03/04/2014 05:00 PM, Kevin L. Mitchell wrote:
> On Tue, 2014-03-04 at 12:11 -0800, Dan Smith wrote:
>> Now, the actual concern is not related to any of that, but about whether
>> we're going to open this up as a new thing we support. In general, my
>> reaction to adding new APIs people expect
Hey y'all,
To avoid cross-posting, please inform your -infra / -operations buddies about
this post.
We've just started thinking about where notification schema files should live
and how they should be deployed. Kind of a tricky problem. We could really use
your input on this problem ...
The
From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 3:51 PM
>On Nov 20, 2014, at 8:12 AM, Sandy Walsh wrote:
>> Hey y'all,
>>
>> To avoid cross-posting, please inform your -infra / -operations buddies
about this post.
>>
>
>
>From: Eoghan Glynn [egl...@redhat.com] Thursday, November 20, 2014 5:34 PM
>
>Some questions/observations inline.
>
>> Hey y'all,
>>
>> To avoid cross-posting, please inform your -infra / -operations buddies
>> about this post.
>>
>> We've just started th
>From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 5:09 PM
>On Nov 20, 2014, at 3:40 PM, Sandy Walsh wrote:
>> From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 3:51
>> PM
>>> On Nov 20, 2014, at 8:12 AM, Sandy Walsh
>From: Eoghan Glynn [egl...@redhat.com] Friday, November 21, 2014 11:03 AM
>> >> Some problems / options:
>> >> a. Unlike Python, there is no simple pip install for text files. No
>> >> version control per se. Basically whatever we pull from the repo. The
>> >> problem with a git clone is we need t
>From: Jay Pipes [jaypi...@gmail.com] Wednesday, November 26, 2014 5:22 PM
>On 11/20/2014 08:12 AM, Sandy Walsh wrote:
>>
>> We're early in thinking about these problems, but would like to start the
>> conversation now to get your opinions.
>>
>
>OK, so th
>From: Eoghan Glynn [egl...@redhat.com] Tuesday, November 25, 2014 1:49 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] Where should Schema files live?
>
>> I think Doug's suggestion of keeping the schema files in-tree and pushing
>> them to a well
>From: Michael Still [mi...@stillhq.com] Thursday, November 27, 2014 6:57 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [nova] is there a way to simulate thousands or
>millions of compute nodes?
>
>I would say that supporting millions of compute
>From: Duncan Thomas [duncan.tho...@gmail.com]
>Sent: Sunday, November 30, 2014 5:40 AM
>To: OpenStack Development Mailing List
>Subject: Re: [openstack-dev] Where should Schema files live?
>
>Duncan Thomas
>On Nov 27, 2014 10:32 PM, "Sandy Walsh" wrote:
>>
>From: Sandy Walsh [sandy.wa...@rackspace.com] Monday, December 01, 2014 9:29 AM
>
>>From: Duncan Thomas [duncan.tho...@gmail.com]
>>Sent: Sunday, November 30, 2014 5:40 AM
>>To: OpenStack Development Mailing List
>>Subject: Re: [openstack-dev] Where should Schema
Hey y'all
Eddie Sheffield has pulled together a strawman set of notification schemas for
Nova and Glance. Looks like a great start for further discussion. He's going to
add JSON-Schema validation next as a form of unit test. Then I guess we have to
start thinking about a library to digest these
n 01/18/2015 04:39 PM, Sandy Walsh wrote:
>
> > Eddie Sheffield has pulled together a strawman set of notification
> > schemas for Nova and Glance.
> >
> > https://github.com/StackTach/notification-schemas
>
> Some important things that I see are missing, so far...
Also, I find setting this in my localrc/local.conf helps debugging:
# get an actual log file vs. screen scrollback
LOGFILE=/opt/stack/logs/stack.sh.log
# gimme all the info
VERBOSE=True
# don't pull from git every time I run stack.sh
RECLONE=False
# make the logs readable
LOG_COLOR=False
On 5/6/2014 10:04 AM, Thierry Carrez wrote:
> John Dickinson wrote:
>> One of the advantages of the program concept within OpenStack is that
>> separate code projects with complementary goals can be managed under the
>> same program without needing to be the same codebase. The most obvious
>> ex
On 5/6/2014 1:48 PM, Thierry Carrez wrote:
> Sandy Walsh wrote:
>> I'd be curious to know more what "managed" means in this situation? Is
>> the core project expected to allocate time in the IRC meeting to the
>> concerns of these adjacent projects? What if th
Great to see efforts to ensure we only send useful notifications.
On 5/23/2014 7:48 AM, Denis Makogon wrote:
Good day, Trove community.
I would like to start thread related to Trove notification framework.
Notification design was defined as: “Trove will emit events for resources
as
On 6/17/2014 7:04 AM, Eoghan Glynn wrote:
> Folks,
>
> A question for the taskflow ninjas.
>
> Any thoughts on best practice WRT $subject?
>
> Specifically I have in mind this ceilometer review[1] which adopts
> the approach of using very fine-grained tasks (at the level of an
> individual alarm ev
DSL's are tricky beasts. On one hand I like giving a tool to
non-developers so they can do their jobs, but I always cringe when the
DSL reinvents the wheel for basic stuff (compound assignment
expressions, conditionals, etc).
YAML isn't really a DSL per se, in the sense that it has no language
con
little similar to what taskflow is trying to do (I am of
>> course biased).
>>
>> I agree with letting the native language implement the basics (expressions,
>> assignment...) and then building the "domain" ontop of that. Just seems more
>> natural IMHO, an
Yep, great idea. Do it.
On 03/07/2014 02:53 AM, Chris Behrens wrote:
>
> On Mar 6, 2014, at 11:09 AM, Russell Bryant wrote:
> […]
>> I think a dedicated git repo for this makes sense.
>> openstack/nova-blueprints or something, or openstack/nova-proposals if
>> we want to be a bit less tied to la
You may want to consider StackTach for troubleshooting (that's what it was
initially created for)
https://github.com/rackerlabs/stacktach
It will consume and record the events as well as give you a gui and cmdline
tools for tracing calls by server, request_id, event type, etc.
Ping me if you
Big +1
From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, March 20, 2014 8:18 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Marconi][TC] Withdraw graduation request
This is a very mature stance and well-written email. Thanks, Flav
On 03/31/2014 10:55 AM, Gordon Sim wrote:
> I believe that ordering of notifications at different levels is not
> guaranteed when receiving those notifications using a notification
> listener in olso.messaging.
>
> I.e. with something like:
>
> notifier = notifier.Notifier(get_transport(CONF
On 04/02/2014 05:47 PM, Gordon Chung wrote:
> I'd like to announce my candidacy for PTL of Ceilometer.
Woot!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 04/15/2014 10:07 AM, George Monday wrote:
> Hey there,
>
> I've got a quick question about the RabbitMQ exchanges. We are writing
> listeners
> for the RabbitMQ exchanges. The basic information about the tasks like
> compute.instance.create.[start|stop] etc. as stored in the 'payload'
> attri
Hey Phil, (sorry for top-post, web client)
There's no firm rule for requiring .start/.end and I think your criteria
defines it well. Long running transactions (or multi complex-step transactions).
The main motivator behind .start/.end code was .error notifications not getting
generated in many
+1, the high-level code should deal with top-level exceptions and generate
.error notifications (though it's a little spotty). Ideally we shouldn't need
three events for simple operations.
The use of .start/.end vs. logging is a bit of a blurry line. At its heart a
notification should provide
>
>From: Jay Pipes [jaypi...@gmail.com]
>Sent: Monday, September 22, 2014 11:51 AM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev] [Nova] - do we need .start and .end notifications
>in all cases ?
>
>On 09/22/20
>From: Chris Dent [chd...@redhat.com] Tuesday, October 07, 2014 12:07 PM
>
>On Wed, 3 Sep 2014, Sandy Walsh wrote:
>
>> Good goals. When Producer and Consumer know what to expect, things are
>> good ... "I know to find the Instance ID ". When the consumer
>>
>
>From: Sandy Walsh [sandy.wa...@rackspace.com] Tuesday, October 07, 2014 6:07 PM
>
>Haven't had any time to get anything written down (pressing deadlines with
>StackTach.v3) but open to suggestions. Perhaps we should just add something to
>the olso.messaging etherpad to
From: Doug Hellmann [d...@doughellmann.com] Tuesday, October 14, 2014 7:19 PM
> It might be more appropriate to put it on the cross-project session list:
> https://etherpad.openstack.org/p/kilo-crossproject-summit-topics
Done ... thanks!
___
OpenStack
Does this mean we're losing request-id's?
Will they still appear in the Context objects?
And there was the effort to keep consistent request-id's in cross-service
requests, will this deprecation affect that?
-S
From: Steven Hardy [sha...@redhat.com]
Sen
20, 2014 at 02:17:54PM +, Sandy Walsh wrote:
> Does this mean we're losing request-id's?
No, it just means the implementation has moved from oslo-incubator[1] to
oslo.middleware[2].
The issue I'm highlighting is that those projects using the code now have
to update their a
Nice work Angus ... great idea. Would love to see more of this.
-S
From: Angus Salkeld [asalk...@mirantis.com]
Sent: Friday, October 24, 2014 1:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [all] How can we get mor
Hey y'all!
I'm taking a page from Angus and trying to pull together a list of StackTach
users. We're moving quickly on our V3 implementation and I'd like to ensure
we're addressing the problems you've faced/are facing with older versions.
For example, I know initial setup has been a concern an
Thanks ... we'll be sure to address your concerns.
And there's the list we've compiled here:
https://etherpad.openstack.org/p/kilo-crossproject-summit-topics
(section 4)
-S
From: Chris Dent [chd...@redhat.com]
Sent: Friday, October 24, 2014 2:45 PM
To: O
https://etherpad.openstack.org/p/kilo-crossproject-notifications
The big takeaways:
1. We want the schema to be external so other languages can utilize them.
2. JSON-Schema seems fine, but AVRO has traction in the Big Data world and
should be considered.
3. The challenge of have text-file based
Nice ... that's always bugged me.
From: wu jiang [win...@gmail.com]
Sent: Thursday, June 26, 2014 9:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Why is there a 'None' task_state between
'SCHEDULING' & '
Something to consider is the "create the queue in advance" feature is done for
notifications, so we don't drop important messages on the floor by having an
Exchange with no associated Queue.
For RPC operations, this may not be required (we assume the service is
available). If this check is trul
7;t need this feature. We should be able to disable it for RPC in
oslo.messaging.
(I say "should" because I'm not positive some aspect of openstack doesn't
depend on the queue existing. Thinking about the scheduler mostly)
-S
On 06/27/2014 05:16 PM, Sandy Walsh wrote:
Some
woot!
From: Mike Bayer [mba...@redhat.com]
Sent: Monday, June 30, 2014 1:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [oslo] Openstack and SQLAlchemy
Hi all -
For those who don't know me, I'm Mike Bayer
On 7/10/2014 5:52 AM, Eoghan Glynn wrote:
> TL;DR: do we need to stabilize notifications behind a versioned
>and discoverable contract?
Thanks for dusting this off. Versioning and published schemas for
notifications are important to the StackTach team. It would be nice to
get this resolve
On 7/10/2014 2:59 PM, Daniel Dyer wrote:
> From my perspective, the requirement is to be able to have a consistent and
> predictable format for notifications that are being sent from all services.
> This means:
> 1. a set of required fields that all events contain and have consistent
> meaning
>
On 7/10/2014 12:10 PM, Chris Dent wrote:
> On Thu, 10 Jul 2014, Julien Danjou wrote:
>
>> My initial plan was to leverage a library like voluptuous to do schema
>> based validation on the sender side. That would allow for receiver to
>> introspect schema and know the data structure to expect. I did
On 7/11/2014 6:04 AM, Chris Dent wrote:
> On Fri, 11 Jul 2014, Eoghan Glynn wrote:
>
>> But I guess you're suggesting not only that we version/schematize
>> individual notification payloads, but that we do so in a way that's
>> global across event types and emitters?
> That's partially correct. I'm
On 7/15/2014 3:51 AM, Mark McLoughlin wrote:
> On Fri, 2014-07-11 at 10:04 +0100, Chris Dent wrote:
>> On Fri, 11 Jul 2014, Lucas Alvares Gomes wrote:
>>
>>> The data format that Ironic will send was part of the spec proposed
>>> and could have been reviewed. I think there's still time to change it
On 7/11/2014 6:08 AM, Chris Dent wrote:
> On Fri, 11 Jul 2014, Lucas Alvares Gomes wrote:
>
>> The data format that Ironic will send was part of the spec proposed
>> and could have been reviewed. I think there's still time to change it
>> tho, if you have a better format talk to Haomeng which is th
If all you want to do is publish a notification you can use oslo.messaging
directly. Or, for something lighter weight, we have Notabene, which is a small
wrapper on Kombu.
An example of how our notification simulator/generator uses it is available
here:
https://github.com/StackTach/notigen/blob
Nachi ... love it!
It would be very cool to see how this would work with Events, since they
have much more metadata associated with them.
This is the sort of stuff I think we should be doing a lot more of.
There are so many excellent open source monitoring components out there.
Better integration
That's awesome Dan!
Now perhaps I can sleep at night :)
From: Dan Prince [dpri...@redhat.com]
Sent: Thursday, October 03, 2013 2:07 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] SmokeStack welcomes Heat and Ceilometer
Hi all,
A quick
Hey y'all,
I've been looking at the reporting framework being put together in oslo [1] and
was wondering about using this for other purposes than guru meditation [2].
In StackTach we generate a number of critical reports around usage, billing,
performance and errors. Currently we store these r
Hi Aparna,
These posts are a little out of date (written during the switch to openstack
common/oslo), but might help?
http://www.sandywalsh.com/2012/04/openstack-nova-internals-pt1-overview.html
http://www.sandywalsh.com/2012/09/openstack-nova-internals-pt2-services.html
If you find they're ter
On 10/10/2013 06:16 PM, Neal, Phil wrote:
> Greetings all, I'm looking at how to expand the ability of our CM
> instance to consume notifications and have a quick question about
> the configuration and flow...
>
> For the notifications central agent , we rely on the services (i.e.
> glance, cin
On 10/15/2013 12:28 PM, Neal, Phil wrote:
>
>
>> -Original Message-----
>> From: Sandy Walsh [mailto:sandy.wa...@rackspace.com]
>> Sent: Thursday, October 10, 2013 6:20 PM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Ceil
Notifications work great.
Actually StackTach has a web interface where you can watch the notifications
coming through in real-time. We're slowing trying to get Ceilometer to have
this functionality.
StackTach works with Nova and Glance events currently.
https://github.com/rackerlabs/stacktach
(Sorry for the top-post ... web client)
So long as you configure each of the services to publish on the same
notification topic [1], they'll all end up in the same queue. Then you can use
anything that can consume from that queue to get your messages. Note that there
are .info, .error and .warn
Here's the current adoption of notifications in OpenStack ... hope it helps!
http://www.sandywalsh.com/2013/09/notification-usage-in-openstack-report.html
-S
From: Qing He [qing...@radisys.com]
Sent: Monday, October 28, 2013 8:48 PM
To: OpenStack Developm
Hey y'all,
Here are a few notes I put together around some ideas for alarm improvements.
In order to set it up I spent a little time talking about the Ceilometer
architecture in general, including some of the things we have planned for
IceHouse.
I think Parts 1-3 will be useful to anyone look
On 10/30/2013 03:10 PM, Steven Dake wrote:
> I will -2 any patch that adds zookeeper as a dependency to Heat.
Certainly any distributed locking solution should be plugin based and
optional. Just as a database-oriented solution could be the default plugin.
Re: the Java issue, we already have opt
this test splitting in general anyway.
-S
On 10/30/2013 04:20 PM, Sandy Walsh wrote:
>
>
> On 10/30/2013 03:10 PM, Steven Dake wrote:
>> I will -2 any patch that adds zookeeper as a dependency to Heat.
>
> Certainly any distributed locking solution should be plugin based
On 10/30/2013 04:44 PM, Robert Collins wrote:
> On 31 October 2013 08:37, Sandy Walsh wrote:
>> Doh, sorry, left out the important part I had originally intended.
>>
>> The ZK unit tests could be split to not run by default, but if you're a
>> ZK shop ... run
On 10/30/2013 08:08 PM, Steven Dake wrote:
> On 10/30/2013 12:20 PM, Sandy Walsh wrote:
>>
>> On 10/30/2013 03:10 PM, Steven Dake wrote:
>>> I will -2 any patch that adds zookeeper as a dependency to Heat.
>> Certainly any distributed locking solution should be plug
On 10/31/2013 11:43 AM, Monty Taylor wrote:
>
> Yes. I'm strongly opposed to ZooKeeper finding its way into the already
> complex pile of things we use.
Monty, is that just because the stack is very complicated now, or
something personal against ZK (or Java specifically)?
Curious.
-S
>
> _
On 10/30/2013 11:37 PM, Robert Collins wrote:
> This is a bit of a social norms thread
>
> I've been consistently asking for tests in reviews for a while now,
> and I get the occasional push-back. I think this falls into a few
> broad camps:
>
> A - there is no test suite at all, adding one
On 06/19/2013 05:54 PM, Russell Bryant wrote:
> On 06/17/2013 05:09 PM, Brian Elliott wrote:
>>
>> On Jun 17, 2013, at 3:50 PM, Chris Behrens wrote:
>>
>>>
>>> On Jun 17, 2013, at 7:49 AM, Russell Bryant wrote:
>>>
On 06/16/2013 11:25 PM, Dugger, Donald D wrote:
> Looking into the sche
While StackTach is still under active development and has undergone many
awesome enhancements since that page was written, we're working on porting it
all to Ceilometer (CM).
Recently, CM added a UDP Collector, but don't think it's been tested against
Tach. Tach + statsd + graphite is still a
1 - 100 of 159 matches
Mail list logo
