[openstack-dev] [nova] need input on possible API change for bug #1420848

Christopher Yeoh cbkyeoh at gmail.com
Thu Mar 12 13:32:51 UTC 2015


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

>
> > 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150313/bb426562/attachment.html>


More information about the OpenStack-dev mailing list