[Openstack] Standardizing External APIs
I'm working on an incident system that my company, as an OpenStack operator, will use to support our deployment of OpenStack. Our first features all involve outside tools creating incidents, but It seems like it would be beneficial to define a standard incident API so that core openstack components could send incidents directly. Or at least so that 3rd party tools that work with OpenStack could have an incident API. I'm assuming an incident system falls outside the OpenStack mission, and I'd expect most operators would want to have their people work incidents via their existing system. So, it seems like defining an implementation independent, OpenStack compatible RESTful API for incidents would be a good thing. I'd expect the API to have adapters for various common incident systems. Note that such an API and adapter set would probably be widely reuseable beyond just Openstack. Does this seem like something that would benefit the community? Is there a way to define just an API as being part of OpenStack, as a way to declare it fit for depending on by OpenStack? This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
2011/9/7 Bryan Taylor btay...@rackspace.com: I'm working on an incident system that my company, as an OpenStack operator, will use to support our deployment of OpenStack. Can you explain what you mean by incidents? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
Sorry do you mean by security incidents ? kindly explain /Zeeshan On Wed, Sep 7, 2011 at 2:20 PM, Soren Hansen so...@linux2go.dk wrote: 2011/9/7 Bryan Taylor btay...@rackspace.com: I'm working on an incident system that my company, as an OpenStack operator, will use to support our deployment of OpenStack. Can you explain what you mean by incidents? -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
+1 From: George Reese [george.re...@enstratus.com] This should fall under the more general push notifications API. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
I meant what is the use case since i have used eucalyptus in production and now using opennebula for venus-c.eu project, so i want to see what is the usecase/userstory for this push notification idea. /Zee On Wed, Sep 7, 2011 at 3:52 PM, Sandy Walsh sandy.wa...@rackspace.comwrote: +1 From: George Reese [george.re...@enstratus.com] This should fall under the more general push notifications API. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
use case ? /Zee On Wed, Sep 7, 2011 at 3:02 PM, George Reese george.re...@enstratus.comwrote: This should fall under the more general push notifications API. On Sep 7, 2011, at 6:20 AM, Soren Hansen wrote: 2011/9/7 Bryan Taylor btay...@rackspace.com: I'm working on an incident system that my company, as an OpenStack operator, will use to support our deployment of OpenStack. Can you explain what you mean by incidents? -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217 f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
See: http://broadcast.oreilly.com/2011/04/proposal-for-cloud-state-notifications.html and http://broadcast.oreilly.com/2010/02/towards-event-driven-cloud-apis.html On Sep 7, 2011, at 7:52 AM, Sandy Walsh wrote: +1 From: George Reese [george.re...@enstratus.com] This should fall under the more general push notifications API. This email may include confidential information. If you received it in error, please delete it. -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
Great links ... thanks George. Sounds very much like the work that cerberus and dragon have done http://www.mail-archive.com/openstack@lists.launchpad.net/msg02278.html https://github.com/Cerberus98/yagi http://wiki.openstack.org/SystemUsageData -S From: George Reese [george.re...@enstratus.com] Sent: Wednesday, September 07, 2011 10:41 AM To: Sandy Walsh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Standardizing External APIs See: http://broadcast.oreilly.com/2011/04/proposal-for-cloud-state-notifications.html and http://broadcast.oreilly.com/2010/02/towards-event-driven-cloud-apis.html On Sep 7, 2011, at 7:52 AM, Sandy Walsh wrote: +1 From: George Reese [george.re...@enstratus.com] This should fall under the more general push notifications API. This email may include confidential information. If you received it in error, please delete it. -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
An incident is a form of ticket that recognizes that an existing requirement (customer or internal) isn't being met. On 09/07/2011 06:20 AM, Soren Hansen wrote: 2011/9/7 Bryan Taylorbtay...@rackspace.com: I'm working on an incident system that my company, as an OpenStack operator, will use to support our deployment of OpenStack. Can you explain what you mean by incidents? This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
I'm skeptical, because usually ticket creation has to be a two way interaction because the entity asking for the ticket has to know that it succeeded end to end and should receive a URI back so that they can record it. There should be a well defined API that forms the boundary between OpenStack specific code and backend integration code. You could use a push API, but you'd have to listen to it with a client that was aware of OpenStack semantics. There's no reason an incident service would want to maintain that and you wouldn't want them too, either. On 09/07/2011 07:02 AM, George Reese wrote: This should fall under the more general push notifications API. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
On Sep 7, 2011, at 1:19 PM, Bryan Taylor wrote: An incident is a form of ticket that recognizes that an existing requirement (customer or internal) isn't being met. On 09/07/2011 06:20 AM, Soren Hansen wrote: 2011/9/7 Bryan Taylorbtay...@rackspace.com: I'm working on an incident system that my company, as an OpenStack operator, will use to support our deployment of OpenStack. Can you explain what you mean by incidents? Presumably you mean creating a support ticket when an error condition is reported by OpenStack? For Nova (compute) we have a notification api that reports various conditions. Nova itself would not interface with a ticketing (aka incident management) system. The api's are all different, a fair amount of custom business logic would be needed to figure out what events in nova would constitute something 'incident' worthy, and it's really outside the domain of the compute service. Instead, you would have a separate app that would subscribe to the notifications (they are published in Atom format and can be pushed via pubsubhubub.), make the business case decisions, and call whatever api the incident system has. -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Standardizing External APIs
On 09/07/2011 02:55 PM, Monsyne Dragon wrote: Presumably you mean creating a support ticket when an error condition is reported by OpenStack? For Nova (compute) we have a notification api that reports various conditions. Yes. Nova itself would not interface with a ticketing (aka incident management) system. The api's are all different, a fair amount of custom business logic would be needed to figure out what events in nova would constitute something 'incident' worthy, and it's really outside the domain of the compute service. Instead, you would have a separate app that would subscribe to the notifications (they are published in Atom format and can be pushed via pubsubhubub.), make the business case decisions, and call whatever api the incident system has. So imagine that OpenStack drives the API. Then OpenStack components could talk to it in a language they understand. Whether this would be Nova directly, or another component just for this, or maybe a control panel or other 3rd party tooling, is something the community could figure out. The vendors might want to help write the adapter from the API to their system, but if not, contributors could scratch their itches as needed. The point is to make this: OpenStack - OpenStack Incident API - Adapters - Vendor Tools This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
