Redfish Code Generation

[Richard Hanley]

Hi James,

I do not have a white paper yet, but I will be putting one together.
Overall, there are two broad areas that I'm thinking about here.

The first is that I get the feeling that there is a growing need to work
directly with the Redfish data model.  If the industry is indeed moving
towards RDE for expansion components, then there will eventually be some
need to serialize Redfish schemas to/from BEJ.  Moreover, here at Google
I'm expecting that we will need to convert the Redfish data model from JSON
to protocol buffers in order to integrate into our data centers.

Tasks like these seem like decent candidates for automation, because it's
primarily about data not logic.  I agree with you're point that a lot of
the logic in bmcweb is around the d-bus layer.  So I'll make sure to avoid
mixing the two problems together.

The other thing that I'm hoping, is that once you have some tooling to
generate the data model, then you can start building up some testing and
validation.  This could be as simple as providing some compile time type
checking, and runtime assertions.  I could imagine it growing to validate
Redfish profiles, but let's not get too far ahead of myself.

You also make a good point about code size.  I could imagine code
generation done in a bad way would bloat the code.  I'll make sure to keep
that in the forefront of any design.

Thanks,
Richard

On Fri, Nov 8, 2019 at 11:49 AM James Feist <james.feist at linux.intel.com>
wrote:

> On 11/8/19 9:42 AM, Richard Hanley wrote:
> > Hi everyone,
> >
> > I was considering work on spiking out a tool to parse Redfish OpenAPI
> > schemas, and create some minimal code generation.  Most of the existing
> > swagger tools I've found for Open API are either for clients or too
> > heavy weight for embedded use.
> >
> > Has anyone in the community looked into this subject?  Would people be
> > interested in such a tool? Are there any pitfalls that people found that
> > I should be aware of?
>
> I heard at the hackathon that a couple of vendors have tried / are doing
> this, and most of the pitfalls were size. OpenBmc also makes the problem
> more interesting as the schemas aren't normally all that difficult to
> create, it's negotiating with dbus, limiting the api calls, and all the
> interfaces that seems to cause most of the problems. I'd be interested
> in what code you're trying to generate and what problem you're trying to
> solve. If you have some sort of white paper I'd be willing to give
> feedback.
>
> -James
>
> >
> > Thank you,
> > Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191108/143227db/attachment-0001.htm>