Redfish on OpenBMC

[Tanous, Ed]

> 
> I'm curious: "not open source yet"? So, you have two forks of this codebase?
> It sounds like you have an internal Intel one and this one that you are
> migrating code between. How does that process work?
> 
There are two answers to that.  I have a short-lived fork that isn't public.  Essentially all Intel patches that you see were reviewed on our internal fork before they were pushed external.  We try to keep the lag time as short as we can (the goal is < 1 week of lag) between our master and public master for things that are considered "done".  It might be longer for short term hacks specific to our platforms.
Specifically for the more generic redfish, we started with an attempt to make it a general purpose redfish server, but hit some snags between the ideal generic solution, and getting something that worked for openbmc.  Our priority shifted a bit to a more requirements driven approach, so the "make it a general solution" work was pushed out, and the patchsets abandoned (for now).  We learned a lot from the schemas we've implemented so far, and I suspect our next run at a plugin system will go much better than the first did.

> 
> I'll have to take a look at the source, because I think you interpreted the
> question differently than I intended.
> 
I suspect the real answer depends on what you want to change.  We should probably come up with a set of use cases for OEM extensions, and see what we can implement.

> 
> I can agree on baselining the benchmarking so we compare apples to apples.
> I have access to only Nuvoton system, though, so I'd have to work on getting
> my stuff tested on AST.
> 
Happy to provide data where I can.  I did get your golang implementation running on my AST platform, and it was quite performant, just too big to be included in the main image.

> 
> Sounds good. I should have added in there OAuth 2.0 support, if we do
> OpenID Connect support at some point, it would be nice to have OAuth
> support to build on.
> 
My knowledge of OAuth support is at 10,000ft view, so I can't really evaluate if it fits into the auth model or not.  I suspect it can be made to work.

> >
> > > 	- Does it implement the redfish standard privilege map model?
> > Patches to do this are in (not open source) review.  We should have a
> discussion about how privilege maps should be backed.
> 
> Same with all of the privilege model questions.
> 
The first round of patchsets internally didn't pass code review, with that said, I will get the patchset rebased and pushed externally so others can look and provide input.

> 
> Meaning, for example, a user with ReadOnly starts an SSE session, that user
> should only get propertychanged for redfish elements that are accessible for
> ReadOnly.
> 
This should be pretty easy to adapt into just about any privilege model, assuming the proposal either reuses one of the HTTP verbs (probably GET) for determining the authorization level required for SSE, or defines a new one in the privileges json.

> > >    - Development: can it run outside of openbmc?
> > Yes, although we're considering dropping this, as it is causing some
> headaches with dependency management and versioning.
> 
> What kind of headaches?

Dependency management.  Right now we build in 2 modes, one where dependencies are pulled in through submodules, and one where dependencies are pulled in using yocto.  We've had build breakages because one got out of sync in versioning.  We've also had minor differences in gcc versions cause problems.  Unit tests throw an additionally wrench in things, and right now are not integrated with yocto builds.  There is also a desire to use c++17 features at some point, which would make it impossible to build on most people's distributions without some toolchain gymnastics.

> 
> Does it do only a self-signed server cert? Or does it create a CA and then sign
> a server cert with the CA?
> 
Right now it generates a private key and a cert, and signs with the private key.  It would only be a couple extra steps to build a CA first, but our current products don't make use of the CA today.  Do you have a use case that needs it?

> Does it pass certificate checks on curl/Linux, curl/macos, and chrome? I had
> to do a bit of work to ensure that everything was compatible across all of the
> combinations of clients. Does it populate commonName and SAN for all local
> IPs?

Right now it's self-signed, so it doesn't pass any cert checks (if I understand what you're asking).  I've used curl/Linux and chrome, and they both function with certificates verification disabled, or if the public key is installed.  Right now commonName is pulled from hostname, which is not ideal and probably should be revisited.
I never thought about populating common name with IP address, because in general the certificate is built on first boot before IP addresses are set or interfaces are enabled, and we didn't want every ip change to trigger a certificate regeneration. With that said.... if it had a CA, maybe it could regenerate without too much trouble?  I should investigate more, but in general, the self-signed cert is not recommended, and is really only there for making the web accessible in development and to upload a fully qualified SSL cert during provisioning.

> Super important. Does it also parallelize all of the backend calls?
Depends on what you mean by parallel;  In the current design, there is a single thread and an async dispatcher (based on boost io_service).  Multiple async operations can be started at a time and finish as the results are available, but the code gets really messy to write.  The best example to look at is the dbus rest implementation below.  Essentially an async transaction needs to track async transaction counts, and when the final transaction is completed (ie the count is zero), finish the HTTP request.

https://github.com/openbmc/bmcweb/blob/master/include/openbmc_dbus_rest.hpp