REST API support on AST 2500 EVB

[Patrick Williams]

Prafulla,

Thank you for your interest and inquiry.

The 1.x release stream is, in some ways, a proof-of-concept of our
vision of a BMC and specifically targeted the Power8-based "Barreleye"
system for Rackspace, which used the AST2400.  Due to aggressive
schedules on that system there were some implementation choices that we
are currently investing time to refactor into a better state.  The
master branch, which will become 2.x, is therefore in a pretty unstable
state and might be the cause of some of what you are seeing.

Most of the developers currently working on the 2.x release stream are
assigned to work on a set of Power9-based systems that will use the
AST2500.  (These are not just IBM developers but a few other companies
are also involved in this effort.)  Obviously, our expertise is in Power
and our current focus is there, but we are trying to be mindful to
not design ourselves into a Power-only BMC.  We would be very excited to
support other processor architectures for the managed server and will
assist where we can.

Since we are working on a few AST2500 machines, we have a subset of the
team that was doing BSP work for that.  This is where the EVB machine
target came from.  This includes u-boot, kernel, and base Yocto.

We also have the other subset of the team working on the [userspace]
management applications to maintain the server.  This part of the team
is still using the AST2400 machines or qemu for most development.

As a result of this split and where we are at with the 2.x development
stream, you are seeing limited functionality depending on which board
you are compiling for.  The EVB target should be very solid on the
u-boot and kernel support but the userspace applications are not
configured correctly or functional.  The QEMU target is using the Yocto
kernel and is more likely to have functional userspace applications.
The machine targets are varied states, but "Barreleye" and "Palmetto"
are both fairly stable.

Your best bet for trying to evaluate the userspace applications is to
use qemuarm or qemux86-64 targets.  As I said, these still are not fully
functional due to where we are at in the development cycle, but might
give you a better view than the raw EVB right now.  We should have a
much different story in about 3 months.

Now, with that background, on to your questions...

> Looks like obmc-rest is running (according to “ps”) and there are
> services listening on ports 22, 3000, 2200 and 443 (“netstat –lntu”).

* Port 22 is the BMC's ssh (user: root, password: 0penBmc).
* Port 2200 is a ssh-based SOL that relays the server's LPC-based VUART.
* Port 3000 is an http-based debug application that is not meant for
  production.  You should be able to point a web-browser at it.
* Port 443 is the https-based REST server.

The way our application stack is organized is as a set of dbus services
and objects.  The REST server uses dbus introspection to automatically
create corresponding REST APIs from the dbus interfaces.  Port 3000 was
a quick mapping of the dbus into a web-client for developers to use.
Consider it a browser version of 'dbus-send' or 'busctl', but we will be
deprecating it in the near future.  Port 443 is the _real_ REST server
that uses introspection.  This is what is documented at the link you
mentioned.

I would suggest first logging in and then looking at system object out
of the inventory:
* https://github.com/openbmc/docs/blob/master/rest-api.md#logging-in
* https://github.com/openbmc/docs/blob/master/rest-api.md#http-get-operations--url-structure

> We get “HTTP/1.0 404 Not Found” when trying to login to port 3000

This interface does not use login, so you should be able to just point a
browser at it.  It doesn't work with 'curl', etc. very well.

> “HTTP/1.0 400 Bad Request” when we try port 443.

Make sure you are using https, but this should work.  Since this uses
dbus introspection and the EVB does not have the userspace applications
working completely, it is possible that there isn't much there.  I would
expect login to work though.  Please let us know what curl (or other
tool) invocation you are using.  As I mentioned earlier, using QEMU
might give you better results for looking at the REST API at this stage.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160727/903b32e5/attachment.sig>