Open Stack

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 <cbkyeoh at gmail.com>
wrote:

>
>
>
> On Thu, Mar 12, 2015 at 11:19 PM, Christopher Yeoh <cbkyeoh at gmail.com>
> wrote:
>
>> On Wed, 11 Mar 2015 09:32:11 -0600
>> Chris Friesen <chris.friesen at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150313/4e358b5c/attachment.html>