FYI :) you may take a look at doc/source/devref/api_plugins.rst which was merged recently you can take a look at http://lists.openstack.org/pipermail/openstack-dev/2015-March/058493.html and its follow up discussion
Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC From: Chris Friesen <chris.frie...@windriver.com> To: <openstack-dev@lists.openstack.org> Date: 03/11/2015 11:44 PM Subject: Re: [openstack-dev] [nova] need input on possible API change for bug #1420848 I can see how to do a v2 extension following the example given for extended_services.py and extended_services_delete.py. That seems to be working now. I'm not at all clear on how to go about doing the equivalent for v2.1. Does that use the api/openstack/compute/plugins/v3/ subdirectory? Is it possible to do the equivalent to the v2 extended_services.py (where the code in api/openstack/compute/plugins/v3/services.py checks to see if the other extension is enabled) or do I have to write a whole new extension that builds on the output of api/openstack/compute/plugins/v3/services.py? Thanks, Chris On 03/11/2015 09:51 AM, Chen CH Ji wrote: > I would think a on v2 extension is needed > for v2.1 , mircoversion is a way but not very sure it's needed. > > Best Regards! > > Kevin (Chen) Ji 纪 晨 > > Engineer, zVM Development, CSTL > Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com > Phone: +86-10-82454158 > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, > Beijing 100193, PRC > > Inactive hide details for Chris Friesen ---03/11/2015 04:35:01 PM---Hi, I'm > working on bug #1420848 which addresses the issue tChris Friesen ---03/11/2015 > 04:35:01 PM---Hi, I'm working on bug #1420848 which addresses the issue that doing a > > From: Chris Friesen <chris.frie...@windriver.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 03/11/2015 04:35 PM > Subject: [openstack-dev] [nova] need input on possible API change for bug #1420848 > > -------------------------------------------------------------------------------- > > > > > Hi, > > I'm working on bug #1420848 which addresses the issue that doing a > "service-disable" followed by a "service-enable" against a "down" compute node > will result in the compute node going "up" for a while, possibly causing delays > to operations that try to schedule on that compute node. > > The proposed solution is to add a new "reported_at" field in the DB schema to > track when the service calls _report_state(). > > The backend is straightforward, but I'm trying to figure out the best way to > represent this via the REST API response. > > Currently we response includes an "updated_at" property, which maps directly to > the auto-updated "updated_at" field in the database. > > Would it be acceptable to just put the "reported_at" value (if it exists) in the > "updated_at" property? Logically the "reported_at" value is just a > determination of when the service updated its own state, so an argument could be > made that this shouldn't break anything. > > Otherwise, by my reading of > " https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK " it > seems like if I wanted to add a new "reported_at" property I would need to do it > via an API extension. > > Anyone have opinions? > > Chris > > __________________________________________________________________________ > 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 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