<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 11 Mar 2015 09:32:11 -0600<br>
Chris Friesen <<a href="mailto:chris.friesen@windriver.com">chris.friesen@windriver.com</a>> wrote:<br>
<br>
><br>
</span><span class="">> 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 class="">So i think this is the critical point here is this a backwards<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>
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 class="">
<br>
</span>- Add it to v2 and no v2 extension required<br>
<span class="im HOEnZb">- Add it to v2.1 without an extension<br>
- No change required to in terms of microversions because it is lready<br>
</span><span class="im HOEnZb">  in the base v2.1 code<br>
<br>
</span></div><span class="im HOEnZb">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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="im HOEnZb">
<br>
</span><div class="HOEnZb"><div class="h5">> Otherwise, by my reading of<br>
> "<a href="https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK" target="_blank">https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK</a>"<br>
> it seems like if I wanted to add a new "reported_at" property I would<br>
> need to do it via an API extension.<br>
><br>
> Anyone have opinions?<br>
><br>
> Chris<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div></div></div></blockquote></div><br></div></div>