Re: [openstack-dev] [all] how to send messages (and events) to our users
From: Angus Salkeld asalk...@mirantis.commailto:asalk...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, April 9, 2015 6:43 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] how to send messages (and events) to our users On Fri, Apr 10, 2015 at 2:24 AM, Sandy Walsh sandy.wa...@rackspace.commailto:sandy.wa...@rackspace.com wrote: From: Angus Salkeld asalk...@mirantis.commailto:asalk...@mirantis.com Sent: Wednesday, April 8, 2015 8:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] how to send messages (and events) to our users I also want to point out that what I'd actually rather see is that all of the services provide functionality like this. Users would be served by having an event stream from Nova telling them when their instances are active, deleted, stopped, started, error, etc. Also, I really liked Sandy's suggestion to use the notifications on the backend, and then funnel them into something that the user can consume. The project they have, yagi, for putting them into atom feeds is pretty interesting. If we could give people a simple API that says subscribe to Nova/Cinder/Heat/etc. notifications for instance X, and put them in an atom feed, that seems like something that would make sense as an under-the-cloud service that would be relatively low cost and would ultimately reduce load on API servers. an under-the-clould service ? - That is not what I am after here. Yeah, we're using this as an under cloud service. Our notifications are only consumed internally, so it's not a multi-tenant/SaaS solution. What I am really after is a general OpenStack solution for how end users can consume service notifications (and replace heat event-list). Right now there is ceilometer event-list, but as some Ceilometer devs have said, they don't want to store every notification that comes. So is the yagi + atom hopper solution something we can point end-users to? Is it per-tenant etc... However, there is a team within Rax working on this SaaS offering: Peter Kazmir and Joe Savak. I'll let them respond with their lessons on AtomHopper, etc. Great, thanks Sandy. It would be good to see what this is (is it just Zaqar? or something totally different). AtomHopper is an atom-pub server (it's open source: http://atomhopper.org/ ), we use it with Repose (http://openrepose.org/) to support Keystone auth, etc. We use Yagi to read notifications from the rabbit queues and publish notifications in Atom format to a feed. We've been using this setup internally for a couple of years now. As Sandy mentioned, Peter and Joe are working on the project to provide these Atom feeds to end users. Sandy, do you have a write up somewhere on how to set this up so I can experiment a bit? Yagi: https://github.com/rackerlabs/yagi AtomHopper: http://atomhopper.org/ (java warning) The StackTach.v3 sandbox is DevStack-for-Notifications. It simulates notifications (no openstack deploy needed) and it has Yagi set up to consume them. There's also Vagrant scripts to get you going. http://www.stacktach.com/install.html https://github.com/stackforge/stacktach-sandbox and some, slightly older, screencasts on the Sandbox here: http://www.stacktach.com/screencasts.html We're in the #stacktach channel, by all means ping us if you run into problems. Or if a Hangout works better for you, just scream :) Thanks for the help! -Angus __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Need help with Alembic...
You should be able to get the dialect_name from the context in the alembic migration and do something like: if dialect_name == 'sqlite': #Do whacky sqlite stuff hereŠ else: #sane db migration hère... On 8/26/13 1:59 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: I'm getting the same problem with a different migration (mine is complaining that a column already exists) http://paste.openstack.org/show/44512/ I've compared it to the other migrations and it seems fine. -S On 08/26/2013 02:34 PM, Jay Pipes wrote: Hey all, I'm trying to figure out what is going wrong with my code for this patch: https://review.openstack.org/41316 I had previously added a sqlalchemy-migrate migration script to add an event_type table, and had that working, but then was asked to instead use Alembic for migrations. So, I removed the sqlalchemy-migrate migration file and added an Alembic migration [1]. Unfortunately, I am getting the following error when running tests: OperationalError: (OperationalError) table event_type already exists u'\nCREATE TABLE event_type (\n\tid INTEGER NOT NULL, \n\tdesc VARCHAR(255), \n\tPRIMARY KEY (id), \n\tUNIQUE (desc)\n)\n\n' () The migration adds the event_type table. I've seen this error occur before when using SQLite due to SQLite's ALTER TABLE statement not allowing the rename of a column. In the sqlalchemy-migrate migration, I had a specialized SQLite migration upgrade [2] and downgrade [3] script, but I'm not sure how I am supposed to handle this in Alembic. Could someone help me out? Thanks, -jay [1] https://review.openstack.org/#/c/41316/16/ceilometer/storage/sqlalchemy/a lembic/versions/49036dfd_add_event_types.py [2] https://review.openstack.org/#/c/41316/14/ceilometer/storage/sqlalchemy/m igrate_repo/versions/013_sqlite_upgrade.sql [3] https://review.openstack.org/#/c/41316/14/ceilometer/storage/sqlalchemy/m igrate_repo/versions/013_sqlite_downgrade.sql ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Looking for some help understanding default meters
On 8/5/13 8:40 AM, Julien Danjou jul...@danjou.info wrote: On Mon, Aug 05 2013, Thomas Maddox wrote: Thinking about it, the latter option seems to describe a very real concern going forward that didn't occur to me when I was wandering around the code. Specifically regarding option 2a, if message 2 arrives at CM before message 1 because it ended up on a faster route, then message 1 will overwrite the metadata from message 2 and we record an incorrect state. Isn't the nature of network comms for messages at the application layer to potentially be out of order and in the case of UDP, even lost? What is the leftover purpose of resource-show when we can't trust its output to represent the actual state of whatever resource is in question? It seems that timestamps could be used to prevent overwriting of the latest state by checking that the incoming notification doesn't have a timestamp less than the already recorded one. I hope I'm not seeing a problem that doesn't exist here or misunderstanding something. If so, please correct me! No you're absolutely right. Checking the timestamp before we override resource metadata would be a great idea. Would you mind reporting a bug first, so we can schedule to fix it? It's probably good to keep in mind that AMQP does not guarantee order of delivery. At any point in the future, if we need to rely on ordering, we will need to check timestamps too. -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
