Re: [openstack-dev] [nova] need input on possible API change for bug #1420848
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
Re: [openstack-dev] [nova] need input on possible API change for bug #1420848
FWIW I think we need to consider that the API is completely froxen for the V2 API (so this freeze does not apply to v2.1 microversions) except under very serious circumstances and only very high priority bug fixes and only apply this to a suitable microversion bump. We really want to get rid of the V2 API code asap anyway. You can after all request a version number of a per method basis as long as you are talking to v2.1. So the only forced upgrade is the v2-v2.1 transition and those apis should be identical On Fri, Mar 13, 2015 at 12:02 AM, Christopher Yeoh cbky...@gmail.com wrote: On Thu, Mar 12, 2015 at 11:19 PM, Christopher Yeoh cbky...@gmail.com wrote: On Wed, 11 Mar 2015 09:32:11 -0600 Chris Friesen chris.frie...@windriver.com wrote: 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. So i think this is the critical point here is this a backwards compatibly API change or not. Would reporing reported_at in updated_at cause *anyone* any pain. For this reason I think it has to go through as a nova spec (and if you think its not going to cause pain get some people from the mailing list +1 it as backwards API change because it always has been a bug. If that is the conculsion and you just reuse updated_at then the procedure would be: - Add it to v2 and no v2 extension required - Add it to v2.1 without an extension - No change required to in terms of microversions because it is lready in the base v2.1 code If you go the reported_at route the and there no changed to updated_at but the fix is consiered a new feature rather than a bug fix then I think we should seriously consider if it should be fixed in V2 at all because the v2 api is basically frozen and we can just add it as a microversion (don't even need to to support it in v2.1), just api microversion In which case the documents that Kevin pointed to should help - if you have any problems catch me on irc or on return email __ 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] [nova] need input on possible API change for bug #1420848
On Thu, Mar 12, 2015 at 11:19 PM, Christopher Yeoh cbky...@gmail.com wrote: On Wed, 11 Mar 2015 09:32:11 -0600 Chris Friesen chris.frie...@windriver.com wrote: 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. So i think this is the critical point here is this a backwards compatibly API change or not. Would reporing reported_at in updated_at cause *anyone* any pain. For this reason I think it has to go through as a nova spec (and if you think its not going to cause pain get some people from the mailing list +1 it as backwards API change because it always has been a bug. If that is the conculsion and you just reuse updated_at then the procedure would be: - Add it to v2 and no v2 extension required - Add it to v2.1 without an extension - No change required to in terms of microversions because it is lready in the base v2.1 code If you go the reported_at route the and there no changed to updated_at but the fix is consiered a new feature rather than a bug fix then I think we should seriously consider if it should be fixed in V2 at all because the v2 api is basically frozen and we can just add it as a microversion (don't even need to to support it in v2.1), just api microversion In which case the documents that Kevin pointed to should help - if you have any problems catch me on irc or on return email 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
Re: [openstack-dev] [nova] need input on possible API change for bug #1420848
So I've been playing with microversions and noticed that the information about req.ver_obj.matches(start_version, end_version) in the spec doesn't actually match what's in the codebase. 1) The code has req.api_version_request instead of req.ver_obj 2) The spec says that end_version is optional in which case it will match any version greater than or equal to start_version. The code requires both but allows either to be None. If we're going to refer people to the spec, do we maybe want to update the spec to match the code? 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
Re: [openstack-dev] [nova] need input on possible API change for bug #1420848
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 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-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
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
