Add schemas package for API/Schema versioning scheme

[davidallendj]

This PR moves the contents of https://github.com/OpenCHAMI/schemas to SMD to move towards OpenCHAMI/roadmap#78 (comment).

[davidallendj]

I moved the repo but haven't update the import references in SMD. I'm going to go ahead and do that real quick for SMD.

[shunr-hpe]

The hms-xnames project is fairly complete. https://github.com/Cray-HPE/hms-xname
Did you consider using this?

Alternately what you have here is fine. It has the advantage of being simpler and more targeted.

[davidallendj]

Yeah, we use that library in other places but the original schemas repo that we're migrating already had this. I'm not opposed to changing it especially if that means less maintenance burden overall.

[davidallendj]

It might be better to just leave it how it is for now considering ochami is referencing this package.

https://github.com/OpenCHAMI/ochami/blob/e7577b97cedae5d3bc4bf3a514489f46b80b1491/cmd/smd-rfe-add.go#L10
https://github.com/OpenCHAMI/ochami/blob/e7577b97cedae5d3bc4bf3a514489f46b80b1491/pkg/xname/xname.go#L6

On the other hand, it probably wouldn't be that difficult to refactor those instances to use the hms-xname library.

[synackd]

That's because I thought we would exclusively stick with our own schemas repo. The only structs in those references are

• csm.XNameComponents
• csm.RedfishEndpoint

Both of which probably have parallels in hms-xname. If that's the way we want to go, I don't anticipate that it would be too hard to do it in ochami.

[alexlovelltroy]

I'd love to deprecate hms-xname altogether. The service should own the schemas it represents.

[synackd]

Does that mean, in the context of OpenCHAMI, should SMD "own" the xname schema?

[shunr-hpe]

Should OpenCHAMI have a recommend property style for json?
What style do you prefer?

At HPE we plan to go with camel case instead of snake case or pascal case in our other products.
For HPE this means

1. Lower case first letter.
2. Property characters limited to A-Z, a-z, 0-9.
3. Abbreviations treated as words. For example we plan to use resourceUri instead of resourceURI.
   This mostly only applies to REST APIs using json. It wouldn't apply to what property style is used in a given language (i.e. go, python, etc.)

In my experience, and as far as I remember, I've only ever used JSON with camel case, which is probably just due to the corner of software development that I've spent my time in. So it's just my subjective preference to use camel case. Snake case seems like an equally reasonable preference for someone to have.

[shunr-hpe]

This subject probably should be dealt with in its own RFD and future PRs.
I'm fine with this PR being submitted as is.

[rainest]

Existing code breaking with the Go stdlib initialism convention ("URI" rather than "Uri") has been slowly driving me mad :)

Either way we'd really need some automated way to enforce them; human enforcement of format standards is tedious and inconsistent.

We'd want to set up https://github.com/ldez/tagliatelle in golangci-lint and bring existing code in line, but that'll be a breaking change and would need to be coordinated across repos.

[alexlovelltroy]

Do you want to propose tagliatelle to our common quality standards at the dev summit?

[davidallendj]

@shunr-hpe I assume you're referring specifically to the JSON tags in this comment right? I think I've seen snake-case consistently used in our repos thus far.