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