<div dir="ltr">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<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 12:02 AM, Christopher Yeoh <span dir="ltr"><<a href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><span class="">On Thu, Mar 12, 2015 at 11:19 PM, Christopher Yeoh <span dir="ltr"><<a href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@gmail.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><span>On Wed, 11 Mar 2015 09:32:11 -0600<br>
Chris Friesen <<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>> wrote:<br>
<br>
><br>
</span><span>> Hi,<br>
><br>
> I'm working on bug #1420848 which addresses the issue that doing a<br>
> "service-disable" followed by a "service-enable" against a "down"<br>
> compute node will result in the compute node going "up" for a while,<br>
> possibly causing delays to operations that try to schedule on that<br>
> compute node.<br>
><br>
> The proposed solution is to add a new "reported_at" field in the DB<br>
> schema to track when the service calls _report_state().<br>
><br>
> The backend is straightforward, but I'm trying to figure out the best<br>
> way to represent this via the REST API response.<br>
><br>
> Currently we response includes an "updated_at" property, which maps<br>
> directly to the auto-updated "updated_at" field in the database.<br>
><br>
> Would it be acceptable to just put the "reported_at" value (if it<br>
> exists) in the "updated_at" property?  Logically the "reported_at"<br>
> value is just a determination of when the service updated its own<br>
> state, so an argument could be made that this shouldn't break<br>
> anything.<br>
><br>
<br>
<br>
</span></span><span>So i think this is the critical point here is this a backwards<span class=""><br>
compatibly API change or not. Would reporing reported_at in updated_at<br>
cause *anyone* any pain. For this reason I think it has to go through<br>
as a nova spec (and if you think its not going to cause pain get some<br></span>
people from the mailing list +1 it as backwards API change because it<br>
always has been a bug. If that is the conculsion and you just reuse updated_at</span></blockquote><div>then the procedure would be:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span>
<br>
</span>- Add it to v2 and no v2 extension required<span class=""><br>
<span>- Add it to v2.1 without an extension<br>
- No change required to in terms of microversions because it is lready<br>
</span><span>  in the base v2.1 code<br>
<br>
</span></span></div><span>If you go the reported_at route the and there no changed to updated_at<br></span></blockquote><div>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<br></div><div><br></div><div>In which case the documents that Kevin pointed to should help - if you have any problems catch me on irc or on return email <br></div><span class=""></span><br></div></div></div>
</blockquote></div><br></div></div></div>