Re: [openstack-dev] [keystone] Notification When Creating/Deleting a Tenant in openstack
Response below. Best Regards, Lance Bragstad ldbra...@us.ibm.com Nader Lahouti wrote on 02/24/2014 11:31:10 AM: > From: Nader Lahouti > To: "OpenStack Development Mailing List (not for usage questions)" > , > Date: 02/24/2014 11:37 AM > Subject: Re: [openstack-dev] [keystone] Notification When Creating/ > Deleting a Tenant in openstack > > Hi Swann, > > I was able to listen to keystone notification by setting > notifications in the keystone.conf file. I only needed the > notification (CURD) for project and handle it in my plugin code so > don't need ceilometer to handle them. > The other issue is that the notification is only for limited to > resource_id and don't have other information such as project name. The idea behind this when we originally implemented notifications in Keystone was to provide the resource being changed, such as 'user', 'project', 'trust' and the uuid of that resource. From there your plugin and could request more information from Keystone by doing a GET on that resource. This way would could keep the payload of the notification sent minimal in case all the information on the resource wasn't required. > > Thanks, > Nader. > > > On Mon, Feb 24, 2014 at 2:10 AM, Swann Croiset wrote: > > Hi Nader, > > These notifications must be handled by Ceilometer like others [1]. > it is surprising that it does not already identity meters indeed... > probably nobody needs them before you. > I guess it remains to open a BP and code them like I recently did for Heat [2] > > > http://docs.openstack.org/developer/ceilometer/measurements.html > https://blueprints.launchpad.net/ceilometer/+spec/handle-heat-notifications > > 2014-02-20 19:10 GMT+01:00 Nader Lahouti : > > Thanks Dolph for link. The document shows the format of the message > and doesn't give any info on how to listen to the notification. > Is there any other document showing the detail on how to listen or > get these notifications ? > > Regards, > Nader. > > On Feb 20, 2014, at 9:06 AM, Dolph Mathews wrote: > Yes, see: > > http://docs.openstack.org/developer/keystone/event_notifications.html > > On Thu, Feb 20, 2014 at 10:54 AM, Nader Lahouti > wrote: > Hi All, > > I have a question regarding creating/deleting a tenant in openstack > (using horizon or CLI). Is there any notification mechanism in place > so that an application get informed of such an event? > > If not, can it be done using plugin to send create/delete > notification to an application? > > Appreciate your suggestion and help. > > Regards, > Nader. > > ___ > 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 > > > ___ > 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] [nova][oslo] Changes to oslo-incubator sync workflow
Shed a little bit of light on Matt's comment about Keystone removing oslo-incubator code and the issues we hit. Comments below. Best Regards, Lance Bragstad ldbra...@us.ibm.com Doug Hellmann wrote on 02/19/2014 09:00:29 PM: > From: Doug Hellmann > To: "OpenStack Development Mailing List (not for usage questions)" > , > Date: 02/19/2014 09:12 PM > Subject: Re: [openstack-dev] [nova][oslo] Changes to oslo-incubator > sync workflow > > > On Wed, Feb 19, 2014 at 9:52 PM, Joe Gordon wrote: > As a side to this, as an exercise I tried a oslo sync in cinder to see > what kind of issues would arise and here are my findings so far: > https://review.openstack.org/#/c/74786/ > > On Wed, Feb 19, 2014 at 6:20 PM, Matt Riedemann > wrote: > > > > > > On 2/19/2014 7:13 PM, Joe Gordon wrote: > >> > >> Hi All, > >> > >> As many of you know most oslo-incubator code is wildly out of sync. > >> Assuming we consider it a good idea to sync up oslo-incubator code > >> before cutting Icehouse, then we have a problem. > >> > >> Today oslo-incubator code is synced in ad-hoc manor, resulting in > >> duplicated efforts and wildly out of date code. Part of the challenges > >> today are backwards incompatible changes and new oslo bugs. I expect > >> that once we get a single project to have an up to date oslo-incubator > >> copy it will make syncing a second project significantly easier. So > >> because I (hopefully) have some karma built up in nova, I would like > >> to volunteer nova to be the guinea pig. > >> > >> > >> To fix this I would like to propose starting an oslo-incubator/nova > >> sync team. They would be responsible for getting nova's oslo code up > >> to date. I expect this work to involve: > >> * Reviewing lots of oslo sync patches > >> * Tracking the current sync patches > >> * Syncing over the low hanging fruit, modules that work without changing > >> nova. > >> * Reporting bugs to oslo team > >> * Working with oslo team to figure out how to deal with backwards > >> incompatible changes > >> * Update nova code or make oslo module backwards compatible > >> * Track all this > >> * Create a roadmap for other projects to follow (re: documentation) > >> > >> I am looking for volunteers to help with this effort, any takers? > >> > >> > >> best, > >> Joe Gordon > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > Well I'll get the ball rolling... > > > > In the past when this has come up there is always a debate over should be > > just sync to sync because we should always be up to date, or is that > > dangerous and we should only sync when there is a need (which is what the > > review guidelines say now [1]). There are pros and cons: > > > > pros: > > > > - we get bug fixes that we didn't know existed > > - it should be less painful to sync if we do it more often > > > > cons: > > > > - it's more review overhead and some crazy guy thinks we need a special team > > dedicated to reviewing those changes :) > > - there are some changes in o-i that would break nova; I'm specifically > > thinking of the oslo RequestContext which has domain support now (or some > > other keystone thingy) and nova has it's own RequestContext - so if we did > > sync that from o-i it would change nova's logging context and break on us > > since we didn't use oslo context. > > > > For that last con, I'd argue that we should move to the oslo RequestContext, > > I'm not sure why we aren't. Would that module then not fall under > > low-hanging-fruit? > I am classifying low hanging fruit as anything that doesn't require > any nova changes to work. > > +1 > > I think the DB API modules have been a concern for auto-syncing before too > > but I can't remember why now...something about possibly changing the > > behavior of how the nova migrations would work? But if they are already > > using the common code, I don't see the issue. > AFAIK there is already a team working on db api syncing, so I was > thinking of let them deal with it. > > +1 > > Doug > > > > > This is kind of an aside, but I'm kind of confused now about how the syncs > > work with things that fall under oslo.rootwrap or oslo.messaging, like this > > patch [2]. It doesn't completely match the o-i patch, i.e. it's not syncing > > over openstack/common/rootwrap/wrapper.py, and I'm assuming because that's > > in oslo.rootwrap now? But then why does the code still exist in > > oslo-incubator? > > > > I think the keystone guys are running into a similar issue where they want > > to remove a bunch of now-dead messaging code from keystone but can't because > > there are still some things in oslo-incubator using oslo.messaging code, or > > something weird like that. So maybe those modules are considered out of > > scope for this effort until the o-r/o-m code is completely out of o-i? > > For the Keystone work specifically, w
Re: [openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information
Hi Georgy, The following might help with some of the trust questions you have, if you haven't looked at it already: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md As far as storage implementation, trust uses sql and kvs backends. Trusts can be given an expiration but if an expiration is not given the trust is valid until it is explicitly revoked (taken from the link above): Optionally, the trust may only be valid for a specified time period, as defined by expires_at. If noexpires_at is specified, then the trust is valid until it is explicitly revoked. Trusts can also be given 'uses' so that you can set a limit to how many times a trust will issue a token to the trustee. That functionality hasn't landed yet but it is up for review: https://review.openstack.org/#/c/56243/ Hope this helps! Best Regards, Lance Bragstad From: Georgy Okrokvertskhov To: OpenStack Development Mailing List , Date: 01/17/2014 12:11 PM Subject:[openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information Hi, In Solum project we want to use Keystone trusts to work with other OpenStack services on behalf of user. Trusts are long term entities and a service should keep them for a long time. I want to understand what are best practices for working with trusts and storing them in a service? What are the options to keep trust? I see obvious approaches like keep them in a service DB or keep them in memory. Are there any other approaches? Is there a proper way to renew trust? For example if I have a long term task which is waiting for external event, how to keep trust fresh for a long and unpredicted period? Thanks Georgy___ 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] Adding notifications to Horizon
Sandy Walsh wrote on 11/25/2013 10:30:05 AM: > From: Sandy Walsh > To: , > Date: 11/25/2013 10:34 AM > Subject: Re: [openstack-dev] Adding notifications to Horizon > > +1 on the inline method. It makes it clear when a notification should be > emitted and, as you say, handles the exception handling better. This might be a good opportunity to add the decorator from Keystone's notification module to Oslo-incubator, and recycle some of that code. https://github.com/openstack/keystone/blob/master/keystone/notifications.py#L26 I know some projects may require more information to be sent in the event payload: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L783 but a general case (like Keystone) that requires only a UUID of the resource and the type of action being created, the current decorator does this pretty well. https://github.com/openstack/keystone/blob/master/keystone/assignment/core.py#L66 If this is the direction of event notifications in Horizon, it would be nice to settle on one implementation. > > 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 detection. > > More info on "well behaved notifications" in here: > http://www.sandywalsh.com/2013/09/notification-usage-in-openstack-report.html > > Great to see! > > -S > > > On 11/25/2013 11:58 AM, Florent Flament wrote: > > Hi, > > > > I am interested in adding AMQP notifications to the Horizon dashboard, > > as described in the following blueprint: > > https://blueprints.launchpad.net/horizon/+spec/horizon-notifications > > > > There are currently several implementations in Openstack. While > > Nova and Cinder define `notify_about_*` methods that are called > > whenever a notification has to be sent, Keystone uses decorators, > > which send appropriate notifications when decorated methods are > > called. > > > > I fed the blueprint's whiteboard with an implementation proposal, > > based on Nova and Cinder implementation. I would be interested in > > having your opinion about which method would fit best, and whether > > these notifications make sense at all. > > > > Cheers, > > Florent Flament > > > > ___ > > 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 > Best Regards, Lance Bragstad___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal oslo.db lib
I believe there are reviews in Keystone for bring this in: https://review.openstack.org/#/c/38029/ https://review.openstack.org/#/c/38030/ https://blueprints.launchpad.net/keystone/+spec/use-common-oslo-db-code Best Regards, Lance Bragstad Software Engineer - OpenStack Cloud Solutions and OpenStack Development T/L 553-5409, External 507-253-5409 ldbra...@us.ibm.com, Bld 015-2/C118 From: Shake Chen To: OpenStack Development Mailing List , Date: 08/16/2013 09:54 AM Subject:Re: [openstack-dev] Proposal oslo.db lib +1 What about the keystone status in oslo? On Fri, Aug 16, 2013 at 10:40 PM, David Ripton wrote: On 08/16/2013 09:52 AM, Boris Pavlovic wrote: We (OpenStack contributors) done a really huge and great work around DB code in Grizzly and Havana to unify it, put all common parts into oslo-incubator, fix bugs, improve handling of sqla exceptions, provide unique keys, and to use this code in different projects instead of custom implementations. (well done!) oslo-incubator db code is already used by: Nova, Neutron, Cinder, Ironic, Ceilometer. In this moment we finished work around Glance: https://review.openstack.org/#/c/36207/ And working around Heat and Keystone. So almost all projects use this code (or planing to use it) Probably it is the right time to start work around moving oslo.db code to separated lib. We (Roman, Viktor and me) will be glad to help to make oslo.db lib: E.g. Here are two drafts: 1) oslo.db lib code: https://github.com/malor/oslo.db 2) And here is this lib in action: https://review.openstack.org/#/c/42159/ Thoughts? +1. Having to manually paste code from oslo-incubator into other projects is error-prone. Of course it's important to get the library versioning right and do releases, but that's a small cost imposed on just the oslo-db folks to make using this code easier for everyone else. -- David Ripton Red Hat drip...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Shake Chen ___ 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] Proposing Morgan Fainberg for keystone-core
+1 Best Regards, Lance Bragstad Software Engineer - OpenStack Cloud Solutions and OpenStack Development T/L 553-5409, External 507-253-5409 ldbra...@us.ibm.com, Bld 015-2/C118 From: Dolph Mathews To: OpenStack Development Mailing List , Date: 08/06/2013 02:23 PM Subject:[openstack-dev] Proposing Morgan Fainberg for keystone-core Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -Dolph ___ 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] [Oslo-incubator] Request for meeting
Hey Mark, Sorry for the spam, thanks for the notice! Best Regards, Lance Bragstad Software Engineer - OpenStack Cloud Solutions and OpenStack Development T/L 553-5409, External 507-253-5409 ldbra...@us.ibm.com, Bld 015-2/C118 From: Mark McLoughlin To: OpenStack Development Mailing List , Date: 07/18/2013 01:43 PM Subject:Re: [openstack-dev] [Oslo-incubator] Request for meeting Hi, On Thu, 2013-07-18 at 13:15 -0500, Lance D Bragstad wrote: > > Hey all, > > Just wanted to throw a word out to see if we could get an Oslo meeting > scheduled, or if anyone else has some topics that would be relevant to > discuss pertaining to recent Oslo work. I have a change in Oslo that I > would like to discuss, but I don't think it would justify a meeting on it's > own. Just wondering if anyone else had some things to bring up to justify > holding a meeting. > > https://review.openstack.org/#/c/34834/. > > If we don't get one scheduled this week due to late notice I completely > understand. Thanks all! There's a meeting scheduled for tomorrow: http://lists.openstack.org/pipermail/openstack-dev/2013-July/012020.html Cheers, Mark. ___ 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] [Oslo-incubator] Request for meeting
Hey all, Just wanted to throw a word out to see if we could get an Oslo meeting scheduled, or if anyone else has some topics that would be relevant to discuss pertaining to recent Oslo work. I have a change in Oslo that I would like to discuss, but I don't think it would justify a meeting on it's own. Just wondering if anyone else had some things to bring up to justify holding a meeting. https://review.openstack.org/#/c/34834/. If we don't get one scheduled this week due to late notice I completely understand. Thanks all! Best Regards, Lance Bragstad Software Engineer - OpenStack Cloud Solutions and OpenStack Development T/L 553-5409, External 507-253-5409 ldbra...@us.ibm.com, Bld 015-2/C118___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Unified logging and Eventlet conflict
Hey all, I went ahead and pushed up a WIP patch taking into account suggestions from Dims and Doug. I just saw the email from Adam before I put up the patch. Let me know if this is somewhat the direction that we want to take: https://review.openstack.org/#/c/34834/ Thanks all for your time in responding to this. The feedback helps out a lot! Best Regards, Lance Bragstad Software Engineer - OpenStack Cloud Solutions and OpenStack Development T/L 553-5409, External 507-253-5409 ldbra...@us.ibm.com, Bld 015-2/C118 From: Adam Young To: openstack-dev@lists.openstack.org, Date: 06/27/2013 10:37 PM Subject:Re: [openstack-dev] [Keystone] Unified logging and Eventlet conflict On 06/27/2013 08:43 AM, Davanum Srinivas wrote: > Lance, Doug, > Looks like eventlet.patcher.is_monkey_patched(thread) is a reasonable > check to switch to to a thread-local implementation. Doesn't it make more sense to have anything Eventlet based explicitly activated? For Keystone, we have isolated all monkeypatching to be done by the process that starts the Keystone server. Adding an additional call in there to activate the thread local storage for greenthreads is reasonable from our perspective. > > Doug, > did you mean threading.local with WeakValueDictionary? > > -- dims > > On Thu, Jun 27, 2013 at 8:15 AM, Doug Hellmann > wrote: >> This isn't something the deployer controls, so I don't know if we want it to >> go into a config setting. >> >> If we can't detect eventlet being used automatically, we could provide an >> initialization function in the locals module so projects could change the >> behavior when a process starts. The default mode would need to be eventlet, >> for now, but a thread-local implementation seems like an obvious >> alternative. And of course we would need the module to behave as it does now >> if the initialization is not explicitly called. >> >> Doug >> >> On Thu, Jun 27, 2013 at 8:03 AM, Davanum Srinivas wrote: >>> Lance, >>> >>> "is eventlet installed" a strong enough check? given that folks may >>> pick up a python install that has eventlet installed w/o realizing it? >>> >>> Is there a way to check if the openstack process the code is running >>> in is using eventlet or not? or the other choice is a flag in logging >>> conf to switch to a non-eventlet implemenation? >>> >>> -- dims >>> >>> On Wed, Jun 26, 2013 at 8:17 PM, Lance D Bragstad >>> wrote: >>>> Hey all, >>>> >>>> Recently there has been some push to get a unified logging >>>> implementation >>>> pulled from Oslo-incubator into Keystone (Blueprint: >>>> >>>> https://blueprints.launchpad.net/keystone/+spec/unified-logging-in-keystone ). >>>> Keystone has been actively working to isolate eventlet code within >>>> Keystone >>>> and bringing in the current implementation from Oslo-incubator would go >>>> against that work, as /oslo-incubator/openstack/common/log.py imports >>>> /oslo-incubator/openstack/common/local.py which has a dependency on >>>> eventlet >>>> >>>> ( https://github.com/openstack/oslo-incubator/blob/master/openstack/common/local.py#L22 ) >>>> and is used for storing references to contexts. I know there has been a >>>> couple of projects looking to not be dependent on eventlet and thought >>>> this >>>> might be a good topic for the mailing list, especially if these changes >>>> end >>>> up in Oslo-incubator. >>>> >>>> After discussion with a couple of the Keystone members, one option is to >>>> tweak local.py to check if eventlet is even installed (similar to def >>>> _ensure_subprocess here: >>>> >>>> https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/common/cms.py#L11 ) >>>> and if it isn't then try implementing a different WeakLocal store not >>>> using >>>> corolocal.local. Any other ideas on how to approach this are more than >>>> welcome. Thanks! >>>> >>>> >>>> >>>> Best Regards, >>>> >>>> Lance Bragstad >>>> Software Engineer - OpenStack >>>> Cloud Solutions and OpenStack Development >>>> T/L 553-5409, External 507-253-5409 >>>> ldbra...@us.ibm.com, Bld 015-2/C118 >>>> >>>> >>>> ___
[openstack-dev] [Keystone] Unified logging and Eventlet conflict
Hey all, Recently there has been some push to get a unified logging implementation pulled from Oslo-incubator into Keystone (Blueprint: https://blueprints.launchpad.net/keystone/+spec/unified-logging-in-keystone). Keystone has been actively working to isolate eventlet code within Keystone and bringing in the current implementation from Oslo-incubator would go against that work, as /oslo-incubator/openstack/common/log.py imports /oslo-incubator/openstack/common/local.py which has a dependency on eventlet (https://github.com/openstack/oslo-incubator/blob/master/openstack/common/local.py#L22) and is used for storing references to contexts. I know there has been a couple of projects looking to not be dependent on eventlet and thought this might be a good topic for the mailing list, especially if these changes end up in Oslo-incubator. After discussion with a couple of the Keystone members, one option is to tweak local.py to check if eventlet is even installed (similar to def _ensure_subprocess here: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/common/cms.py#L11) and if it isn't then try implementing a different WeakLocal store not using corolocal.local. Any other ideas on how to approach this are more than welcome. Thanks! Best Regards, Lance Bragstad Software Engineer - OpenStack Cloud Solutions and OpenStack Development T/L 553-5409, External 507-253-5409 ldbra...@us.ibm.com, Bld 015-2/C118___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
